Repository navigation
Conversation
Every FactorizedTable zero-filled a 256 KB page for its first flat tuple block, so a one-row RETURN cleared half a megabyte across the dummy scan and the result collector. Flat tuple blocks now count the bytes at their end that are neither zeroed nor written, and claim() zeroes 4 KB at a time as tuples are handed out. Claimed tuples read as zero exactly as before; clear() zeroes only the part that was used. Blocks used for hash slots and sorting still zero up front. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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
1 participant
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 work was produced with the help of language models.
Fixes #1299. Part of #1290.
Every
FactorizedTablezero-filled a full 256 KB page for its first flat tuple block, even for one row.RETURN 1created two (the dummy scan's one-row table and the result collector's), so each query cleared 512 KB: about 13% of a warmRETURN 1.Fix. Flat tuple blocks are taken without zeroing and
DataBlock::claimzeroes 4 KB at a time as tuples are handed out; the block counts the bytes at its end that are neither zeroed nor written. Claimed tuples read as zero exactly as before, andclear()zeroes only the part that was used. Hash-slot and sort blocks still zero up front.Performance.
RETURN 1in a fresh in-memory database, query-summary execute time, median of 8 processes; warm is a C API loop of 20000 queries.Heavy LDBC SF1 queries at one thread: identical rows, instructions within ±0.4%, except a 1M-group aggregate at +0.9% instructions; its cycles stay within run-to-run noise (1747M vs 1756M per execution, median of 8 runs that vary by up to 12%). It zeroes 12 MB less per execution, in more and smaller
memsetcalls. Mallocs per execution are unchanged: 601 forRETURN 1at one thread, and within ±2 on the heavy queries.Tests.
FactorizedTableTest.ClaimedTuplesAreZeroOnRecycledPagesdirties a page, frees it, and checks that tuples handed out from the recycled page are zero across several 4 KB steps, after aresizepast a 4 KB step and afterclear()(fails if a claim stops zeroing).ClaimsAfterMergeKeepCopiedTuples: after a merge copies tuples past the other block's zeroed part, they stay intact and the next tuple handed out is zero (fails without the merge bookkeeping). Full ctest on this branch: 3102/3102.