Fix parameterized view used twice in same query#105170
Merged
Merged
Conversation
…n the same query Fixes #105153. When a parameterized view is referenced multiple times in the same query with different argument values, e.g. SELECT id FROM testing WHERE id IN (SELECT id FROM test_view(id = 'a')) AND id IN (SELECT id FROM test_view(id = 'b')); the analyzer was treating both subqueries as identical. As a result, `CollectSets` keyed the IN-set by `getTreeHash`, found that both subqueries hashed to the same value, and reused the first set for the second IN, silently dropping the second filter. The root cause is in `TableNode::isEqualImpl` and `TableNode::updateTreeHashImpl`: each call to `buildParameterizedViewStorage` creates a fresh `StorageView` whose inner query has the substituted argument values, but the new storage shares the same `StorageID` as the original view. Equality and hashing only looked at `StorageID`, so the two `TableNode`s for `test_view(id = 'a')` and `test_view(id = 'b')` compared as equal and hashed identically. Fix it by mixing the substituted inner query into the tree hash and the equality check whenever the storage is a parameterized view. Non-parameterized tables and views are unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Workflow [PR], commit [5182958] Summary: ✅ AI ReviewSummaryThis PR fixes incorrect deduplication of Final VerdictStatus: ✅ Approve |
clickhouse-gh
Bot
added
the
pr-bugfix
The new test exposes a pre-existing limitation: parameterized views do not work correctly with parallel replicas because parameter substitution happens on the initiator only, and the substituted body is not propagated to remote replicas, which see only the placeholder-bearing view body and fail to resolve identifiers (UNKNOWN_IDENTIFIER). Tracked separately in #84188. CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=105170&sha=324ad58a31419a96f217af5c16f857bbd45eff3f&name_0=PR&name_1=Stateless%20tests%20%28amd_llvm_coverage%2C%20ParallelReplicas%2C%20s3%20storage%2C%20parallel%29
Contributor
LLVM Coverage Report
Changed lines: 82.61% (19/23) · Uncovered code |
robot-ch-test-poll2
added
the
pr-synced-to-cloud
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #105153.
Two calls to the same parameterized view with different argument values in one query (e.g.
id IN (SELECT id FROM test_view(id = 'a')) AND id IN (SELECT id FROM test_view(id = 'b'))) were being deduplicated, so the second filter was silently dropped.Root cause: each call to
buildParameterizedViewStoragecreates a freshStorageViewcarrying the substituted inner query, but it reuses the original view'sStorageID.TableNode::isEqualImpl/updateTreeHashImplonly looked atStorageID, so the twoTableNodes compared equal andCollectSets(which keysPreparedSetsbygetTreeHash) collapsed them into one IN-set.Fix: when the storage is a parameterized view, mix the substituted inner query into the tree hash and the equality check. Non-parameterized tables and views are unaffected.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Fix incorrect results when the same parameterized view is referenced more than once in the same query with different argument values. Previously, the analyzer collapsed the calls into one, silently dropping all but the first filter.
Documentation entry for user-facing changes