ClickHouse / ClickHouse/ClickHouse

max_estimated_execution_time does not take max_rows_to_read into account

Open
#75,337 0 comments 1 reaction 0 assignees View on GitHub
comp-query-execution external unexpected behaviour
Dominant language
C++
Stars
49.9k
Forks
9k
Avg merge
21h 32m
Merged PRs (30d)
515

Description

### Company or project name

_No response_

### Describe the unexpected behaviour

Hi,

First : thanks the whole team behind clickhouse for the great work you do !

Now my question :

max_estimated_execution_time is not documente in details in https://clickhouse.com/docs/en/operations/settings/query-complexity#max_estimated_execution_time and I ran into a issue using it.

Having a query that take 2 minutes and using max_estimated_execution_time=50 will work as expected by breaking early after ~10 seconds.

But then I restricted the query with max_rows_to_read+read_overflow_mode=break with a low value which break the query after 30 seconds only with a partial result. In this case max_estimated_execution_time=50 will still abort the query. I would expect that the estimated execution time to take this case into account.

Neverless, thanks so much for the work!

Best regards,

Damien

### How to reproduce

having a select query taking more tham one minutes "xxxx"
having this same query taking 30 secs when limited to "yyyy" rows

## this will break early due to estimated time regardless it would have completed in less than 50 sec.
SELECT xxxx SETTINGS max_row_to_read=yyy, read_overflow_mode=break, max_estimated_execution_time=50;

### Expected behavior

max_estimated_execution_time will take into account that query will not go through total_rows_approx but only up to max_row_to_read

### Error message and/or stacktrace

_No response_

### Additional context

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.