Allow positional arguments in distributed queries - #94359
Conversation
|
@devcrafter , @KochetovNicolai - I am happy to make any changes in case I'm missing some context |
|
@simonmichal Please add the test |
|
Workflow [PR], commit [d6a2af0] Summary: ✅ AI ReviewSummaryThis PR replaces the previous setting-based workaround with dedicated ClickHouse Rules
Final Verdict
|
d3ab5ae to
fcd82e7
Compare
|
@devcrafter I've added the test, let me know if there's anything else? regarding the failing it seems to me it's unrelated |
alexey-milovidov
left a comment
There was a problem hiding this comment.
This is good, looks almost ready for merge.
fcd82e7 to
6cf8344
Compare
|
@devcrafter , @alexey-milovidov : just a friendly ping to see if there's anything else that needs to be adjusted? |
6cf8344 to
25aaab2
Compare
|
@simonmichal, the test failed. |
|
@alexey-milovidov I beg your pardon, apparently I've been slopy, I've generated the reference with but apparently I didn't run for some reason running: always works (at least on my local setup) however, running it through the testsuit fails I will debug it on the weekend |
44532e6 to
7a9b5c0
Compare
|
@alexey-milovidov , @devcrafter sorry for the delay! It turns out that apparently if the test is execute via I assumed that a view should be always treated as Let me know if this seems OK? |
(1) QueryKind::INITIAL_QUERY is related to query execution on initiator (the node which accept initial query from client), (2) QueryKind::SECONDARY_QUERY when the query or part of the initial query is executed on remote node. For (2) the result of its execution is sent back to the initiator, and there the query execution is finished (the result is sent back to client) |
|
@devcrafter thanks for the clarification! regarding the failing test, what's the nature of is it one of the tests in if marking it as let me know your thoughts! |
I am wondering, in the test environment do both the initiator and the executor run the MR? I am bit puzzlet why the view was not expanded properly on the initiator where the flag is set to |
|
@devcrafter : just a friendly ping, I was wondering if there are suggestions on your side? |
|
@devcrafter @alexey-milovidov : I was just wondering if there's any advice on your side on how to proceed?
I am wondering, if in the test environment both: the initiator and the executor run the MR (that is being tested)? I am bit puzzlet why the view was not expanded properly on the initiator where the flag is set to QueryKind::INITIAL_QUERY - hence my question - it crossed my mind that it might be that only the executor runs the MR and in this case the failure would be a false positive
Please let me know your thoughts! |
Sorry for the delay, I'll check it shortly |
43fc0e4 to
6b93b15
Compare
|
@devcrafter: it’s ready for another review:
|
The `enable_positional_arguments` re-enablement in `StorageView` was gated on `SECONDARY_QUERY`, which only covers remote execution. The local plan path in `DistributedCreateLocalPlan` also disables this setting, so views accessed via `prefer_localhost_replica=1` still failed with `NOT_AN_AGGREGATE`. Always re-enable `enable_positional_arguments` in the view context unconditionally: view definitions need their own positional arguments resolved regardless of execution context. This also addresses the review feedback to avoid depending on `query_kind` for this logic. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM Coverage Report
Changed lines: 100.00% (53/53) · Uncovered code |
|
@devcrafter and @alexey-milovidov: freshly rebased, all green, ready for review ;-) I hope you guys didn't give up on this one — it took me some time, but I think it's now in a good state :-) |
Backport of ClickHouse#94359 to 25.8.16: Allow positional arguments in distributed queries
Antalya 25.8, backport of ClickHouse#94359: Allow positional arguments in distributed queries
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Allow positional arguments in distributed queries
Description
In #62289 positional argument substitution was disabled at remote, however in case of a view that can be expanded only in remote this can lead to
NOT_AN_AGGREGATEerror. This MR enables positional argument substitutions for views.Tests
Using the reproducer from #89940 :
Making sure fix from #62289 is still working:
Version info
26.5.1.391