Array fixes + make validity more lazy #9400
Merged
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 PR started as an investigation of a failing nightly test related to array child-validity masks in combination with vector_size=2, but ended up bundling a couple of small fixes.
STANDARD_VECTOR_SIZE
size, which is probably not equal to the child vector size since its always allocated as a multiple of the array size.As a consequence, ValidtyMasks now contain a "target count" property declaring the desired (or actual) capacity of their validity data, which defaults to
STANDARD_VECTOR_SIZE
but can be set to something else during construction. This target count is then used instead ofSTANDARD_VECTOR_SIZE
when the validity data is actually initialized and allocated, i.e. when.Set(i, true)
or.Initialize()
is made.In effect validitymasks are now even lazier, and in theory we could defer initializing them even when
Resize()
:ing. Although I could not get that to work in this PR (skipping the initialization causes a verification failure in some list-related tests) I am planning to look into that and work on a proper refactor of the ValidityMask code in a followup PR.Closes https://github.com/duckdblabs/duckdb-internal/issues/497