refactor(query): Refactor virtual columns storage & read planning #19284
+2,403
−675
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.
I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/
Summary
This PR focuses on two core refactors:
VirtualColumnReadPlantypes, ensuring any JSON shape can be materialized from the virtual dataset:Example:
v['id']exists as a dedicated column.Example:
v['user']['extra']only appears in a few rows, so it is stored in the shared map.Example:
v['user']is built fromv['user']['id'],v['user']['name'], andv['user']['info'].Example:
v['user']['info']['tags'][0]is derived from the nearest variant parent (e.g.v['user']['info']) and then extracted by keypath.Other changes
VirtualBlockMetamismatches caused bycolumn_iddrift.Notes: This refactor does not attempt to keep compatibility with old virtual-column parquet metadata.
Tests
Type of change
This change is