Automatic decision of nº of parallel replicas#51692
Automatic decision of nº of parallel replicas#51692Algunenano merged 32 commits intoClickHouse:masterfrom
Conversation
|
This is an automated comment for commit a4f5e9e with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page Successful checks
|
9eb5208 to
314b800
Compare
314b800 to
e026911
Compare
|
@nikitamikhaylov The only thing missing right now is the analyzer (which needs a completely different implementation). I don't know how hard it will be to add to the analyzer, but if you want to review the interpreter part we could improve and merge this part separately |
|
Hey @Algunenano can we expect with this PR to exclude a specific replicas when using parallel replicas feature ? |
No. This PR is only meant to decide how many replicas to use based purely on the estimation of rows to read. But note that you can already do what you want by having a cluster without that specific replica or sets of replicas. |
|
So it means I can configure the same cluster with 2 different sets of replicas but still allow the replication between them ? |
Replication is independent on the cluster, but yes, you could have something like this: And use |
|
I've been looking into how to implement this cleanly in the analyzer and I don't see a good way that doesn't involve re-analyzing the query again. To do a proper estimation you need to generate the full optimized pipeline (to get proper prewhere filters and knowledge about affected parts) and at that point changing the parallel replica settings doesn't have the desired effect (be able to disable any remote replica setup if they are not used). I'm going to do some more tests and fallback to full re-analysis if I don't find a better way forward. Even though this is how the current interpreter works (full pipeline regeneration) I'd expect the analyzer to be able to have a better way to change the pipeline dynamically. Maybe it's just me not knowing how the analyzer works or maybe it's not there yet. |
e026911 to
cd90256
Compare
cd90256 to
b6900c8
Compare
|
I've added support for the analyzer too. I'm afraid the approach is bad but I couldn't find a better way that didn't involve me spending several weeks learning how the analyzer works and how I could get the optimized filters from the query into the earlier stage (so the estimation of rows is valid). Note that the test will still fail under the analyzer because it's also testing JOINs with it, and parallel replicas + analyzer + JOIN is not supported. Marking as ready for review now |
cf02904 to
0fcc27c
Compare
0fcc27c to
c5bd297
Compare
5fe94e3 to
bfb5b8f
Compare
| { | ||
| ActionDAGNodes filter_nodes; | ||
| if (table_expression_query_info.filter_actions_dag) | ||
| filter_nodes.nodes = table_expression_query_info.filter_actions_dag->getOutputs(); |
There was a problem hiding this comment.
I'm not sure if we need to pass all filters here or we need to filter them more, like getFiltersForPrimaryKeyAnalysis does for the old interpreter.
There was a problem hiding this comment.
I'm not sure whether additional table filters setting is supported for the Analyzer...
There was a problem hiding this comment.
I'd expect table_expression_query_info.filter_actions_dag to contain all the filter expressions.
And yes, Planner supports additional table filters.
There was a problem hiding this comment.
It seems that passing all filters is ok. buildIndexes will do the heavy work of checking primary key and so on so reducing the list doesn't seem necessary.
| 02721_url_cluster | ||
| 02534_s3_cluster_insert_select_schema_inference | ||
| 02765_parallel_replicas_final_modifier | ||
| 02784_parallel_replicas_automatic_decision_join |
There was a problem hiding this comment.
This test needs the analyzer supporting JOINs with pure parallel replicas
There was a problem hiding this comment.
We do not usually add anything to this list. It was created to disallow introducing incompatibility.
There was a problem hiding this comment.
Parallel replicas with JOINs is not supported with the analyzer yet, so the tests checking the automatic decision on top of that won't work until the underlying feature is implemented. For now I'd rather add tests (with some of those disabled for the analyzer) that not add them at all.
There was a problem hiding this comment.
Then you'll need to work on supporting it with the analyzer because it'll be a blocker.
There was a problem hiding this comment.
I know. My point is that it was already a blocker, it's just more tests for when I implement the feature on the new planner.
|
Failed tests:
For some reason it took 45 minutes from children killed by OOM killer to server fully off: I guess it might be generating dumps and then gdb connections + explorations. In any case, it's unrelated to the changes. Let's merge! |
| { | ||
| ActionDAGNodes filter_nodes; | ||
| if (table_expression_query_info.filter_actions_dag) | ||
| filter_nodes.nodes = table_expression_query_info.filter_actions_dag->getOutputs(); |
There was a problem hiding this comment.
I'd expect table_expression_query_info.filter_actions_dag to contain all the filter expressions.
And yes, Planner supports additional table filters.
| 02721_url_cluster | ||
| 02534_s3_cluster_insert_select_schema_inference | ||
| 02765_parallel_replicas_final_modifier | ||
| 02784_parallel_replicas_automatic_decision_join |
There was a problem hiding this comment.
We do not usually add anything to this list. It was created to disallow introducing incompatibility.
|
novikd
left a comment
There was a problem hiding this comment.
LGTM, but I checked only the code related to Planner and new infrastructure.
| 02721_url_cluster | ||
| 02534_s3_cluster_insert_select_schema_inference | ||
| 02765_parallel_replicas_final_modifier | ||
| 02784_parallel_replicas_automatic_decision_join |
There was a problem hiding this comment.
Then you'll need to work on supporting it with the analyzer because it'll be a blocker.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Documentation entry for user-facing changes
parallel_replicas_min_number_of_granules_to_enable.parallel_replicas_min_number_of_rows_per_replicato decide dynamically how many replicas to use when executing the query. The decision isrow estimation / parallel_replicas_min_number_of_rows_per_replica(integer division).parallel_replicas_min_number_of_granules_to_enable).Still pending: