Madu Mitha Ravi
Madu Mitha Ravi
The performance concern on CPU usage on `limit` query still exists.
### Part 1 - Problem holds The issue still exists, - Light Ingest, about 17 rows/second - No concurrency - For scanning approx. 1440 rows and providing the limit of...
Below is Verbose for LIMIT `ORDER BY time DESC` Q5 (limit 5) verbose explains plan: SortPreservingMergeExec: [time@19 DESC], fetch=5, metrics=[output_rows=5, elapsed_compute=58.748µs] SortExec: TopK(fetch=5), expr=[time@19 DESC], preserve_partitioning=[true], metrics=[output_rows=15, elapsed_compute=234.22µs, row_replacements=26] CoalesceBatchesExec:...
The latency and resource usage are similar between ASC and DESC for LIMIT. Below is Verbose for LIMIT `ORDER BY time ASC` Q5 (limit 5) verbose explains plan: SortPreservingMergeExec: [time@19...
@hiltontj Tried without the predicate, the resource usage is the same and latency is higher than with predicate. Q5 (limit 5) verbose explains ``` plan: SortPreservingMergeExec: [time@19 ASC NULLS LAST],...
@hiltontj IOx team did nice `limit query` optimizations last year, maybe that could be relevant ? I will pull some details.
@hiltontj Here are some PRs, https://github.com/influxdata/influxdb_iox/issues/12205 https://github.com/influxdata/influxdb_iox/pull/12317
This concern still exists, nearly 6 cores is required for limit queries on look backs of 12+ hours.
@adrian-thurston Can you share please?
fyi - Updated the title, the slowness is observed in OSS and PRO.