influxdata / influxdata/influxdb

`window` operations are not pushed down if `option location` is set

Open
#24,293 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
31.7k
Forks
3.7k
Avg merge
13h 37m
Merged PRs (30d)
8

Description

__Steps to reproduce:__

The following query (with no `location`):

```flux
import "profiler"

option profiler.enabledProfilers = ["query", "operator"]

from(bucket: "Cliente")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "data")
\\ other filters omitted for brevity
|> aggregateWindow(every: 1d, fn: first)
|> yield()
```

Gives a `maxAllocated` of approximately 800 bytes and looking at the operator profiler I can see that the whole 1quey has been pushed down (I see only one operation):

|result|table|_measurement|Type|Label|Count|MinDuration|MaxDuration|DurationSum|MeanDuration|
|---|---|---|---|---|---|---|---|---|---|
||1|profiler/operator|*influxdb.readWindowAggregateSource|ReadWindowAggregateByTime19|1|2269362|2269362|2269362|2269362|

If I set the location:

```flux
import "profiler"
import "timezone"

option profiler.enabledProfilers = ["query", "operator"]
option location = timezone.location(name: "Europe/Rome")

from(bucket: "Cliente")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "data")
\\ other filters omitted for brevity
|> aggregateWindow(every: 1d, fn: first)
|> yield()
```

Gives a `maxAllocated` of approximately 2.700.000 bytes and looking at the operator profiler I can see that only the filters have been pushed down:

|result|table|_measurement|Type|Label|Count|MinDuration|MaxDuration|DurationSum|MeanDuration|
|---|---|---|---|---|---|---|---|---|---|
||1|profiler/operator|*influxdb.readFilterSource|merged_ReadRange17_filter2_filter3_filter4_filter5_filter6_filter7_filter8_filter9_filter10|1|47373695|47373695|47373695|47373695|
||1|profiler/operator|*universe.fixedWindowTransformation|window11|6|2798|12463136|49746537|8291089.5|
||1|profiler/operator|*execute.indexSelectorTransformation|first12|126|1654|1633800|2868003|22761.928571428572|
||1|profiler/operator|*table.fillTransformation|experimental/table.fill13|126|137|26452|199982|1587.1587301587301|
||1|profiler/operator|*universe.schemaMutationTransformation|duplicate14|126|809|33083|434832|3451.0476190476193|
||1|profiler/operator|*universe.fixedWindowTransformation|window15|126|910|98258|1029264|8168.761904761905|

__Expected behavior:__
The first and second query should have comparable performance and `window` should be pushdown regardless of `loaction`

__Actual behavior:__
The second query is much less performant

__Environment info:__

* System info: docker (tested both on WSL2 and Debian)
* InfluxDB version: 2.7.1

Contributor guide

Open the contributing guide

Research direction

Reproduce the two Flux queries from the issue with and without the Europe/Rome location and compare the operator profiler output. Trace why aggregateWindow is not pushed down when location is set; done means the window operation is pushed down and the two queries have comparable performance.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
databases, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.