* feat(query): enable min/max pushdown
* fix(query): fix the group last pushdown to use descending cursors
* test(storage): add read group test with no agg
Co-authored-by: Jonathan A. Sternberg <jonathan@influxdata.com>
* fix(storage): Detect need for descending cursor in WindowAggregate
* chore: Format + comments
* chore: PR cosmetic feedback (#21141)
Co-authored-by: Phil Bracikowski <pbracikowski+git@influxdata.com>
* chore: rename testcase and fix comments
Co-authored-by: Phil Bracikowski <pbracikowski+git@influxdata.com>
* refactor: allow newIndexSeriesCursor() to accept an influxql.Expr
In order to let TagKeys and TagValues get the right answer,
sometimes they will need to examine their predicate and
see if using the index is possible, or if a block scan is needed.
For those cases we want to examine the predicate before creating
the index series cursor. This change allows us to create an
index series cursor with an already-deserialized influxql.Expr.
This fixes multi measurement queries that go through the storage service
to correctly pick up all series that apply with the filter. Previously,
negative queries such as `!=`, `!~`, and predicates attempting to match
empty tags did not work correctly with the storage service when multiple
measurements or `OR` conditions were included.
This was because these predicates would be categorized as "multiple
measurements" and then it would attempt to use the field keys iterator
to find the fields for each measurement. The meta queries for these did
not correctly account for negative equality operators or empty tags when
finding appropriate measurements and those could not be changed because
it would cause a breaking change to influxql too.
This modifies the storage service to use new methods that correctly
account for the above situations rather than the field keys iterator.
Some queries that appeared to be single measurement queries also get
considered as multiple measurement queries. Any query with an `OR`
condition will be considered a multiple measurement query.
This bug did not apply to single measurement queries where one
measurement was selected and all of the logical operators were `AND`
values. This is because it used a different code path that correctly
handled these situations.