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.
This is a temporary fix for COPY REL table with VAR_LIST properties.
Previously, we were storing VAR_LIST as
ku_list
entries plus overflow data in separate files. That had been changed for node tables already to a new layout, which consists ofoffsets
anddata
. Details on the new layout can be found here.Now as we are moving rel tables to node group based storage, we are also shifting the layout of VAR_LIST on rel tables to the new one. While the problem is that the new layout is not friendly to partially sorted insertions, as we are sorting tuples based on their src node offsets inside the node group.
Take an example of following tuples (dst is ignored):
The expected layout is:
Existing implementation of VAR_LIST column chunk will always append data to the end of the data column chunk, which would lead to
To solve this problem, this PR introduces an AuxVarListColumnChunk, which would keep lists as
list_entry_t
entires plus data column chunk, and after insertions (during whichColumnChunk::finalize()
is called), every list inside it will be appended to a new VarListColumnChunk in a sorted way.