* feat: flags for pushing down new aggregates
* refactor: grouped aggregate rewrite rules
The storage operation ReadGroup aggregates per series on the storage
side. The planner will rewrite grouped aggregate queries to call
ReadGroup, which will perform a partial aggregation, followed by
another operation that will perform the rest of the aggregation on
the compute side.
* feat: storage capabilities for grouped aggregates
* fix: changes from review
* feat: group read operation name should include aggregate
this ability exports all resources associated with a stack by the same
metadata.name fields as the original application had done it. This can
be used as a means to snapshot the current state of the stack. This can
be used for source control or other means.
closes: #18271
Added a (disabled) planner rule that matches:
ReadGroupPhys -> { count }
It uses the same physical spec node for group to implement the aggregate. The
rule requires:
* the pushDownGroupAggregateCount feature flag enabled
* no existing aggregate present in the ReadGroup
* use of the "_value" column only
This commit checks http.Request.Context().Err() to see if the context
has been canceled before writing an error code. It uses the non-standard
Nginx 499 error code for client disconnection.
Added a (disabled and feature-flagged) planner rule that matches:
ReadRange -> window -> { min, max, mean, count, sum }
The rule requires:
* the pushDownWindowAggregate{Count,Rest} feature flags enabled
* having WindowAggregateCapability
(which StorageReader does not currently have)
* use of "_value" columns only
* window.period == window.every
* window.every.months == 0
* window.every is positive
* window.offset == 0
* standard time columns
* createEmpty is false
this fix is necessary to avoid the superflour write header error. When the
write fails, we log it, this shoudl never happen unless the connection gets
corrupted. In that case there is nothing for the server to do except log
It is solid to use retrieve the method directly from the request.
Co-authored-by: George MacRorie <gmacrorie@influxdata.com>
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
I think it is a nice utility function that I would like to use
elsewhere.
So I decided to move it out to the tracing package.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
With `/health`, it is possible to override the overall status reported.
This change adds the same functionality to `/ready`. This allows
incident responders to take an unhealthy pod out of a service without
killing it—giving them time to gather meaningful forensic data from the
pod. The new contract is:
Force not ready:
GET /ready?force=true&ready=false
Force ready:
GET /ready?force=true&ready=true
Disable override:
GET /ready?force=false