summaryrefslogtreecommitdiff
path: root/src/backend/access/brin
diff options
context:
space:
mode:
authorTomas Vondra <tomas.vondra@postgresql.org>2025-11-04 18:46:37 +0100
committerTomas Vondra <tomas.vondra@postgresql.org>2025-11-04 18:51:17 +0100
commitc98dffcb7c7010d216dc16d22cb594ef7d65fde1 (patch)
treefdaca09585ed8221bad27fb50be953670b14b037 /src/backend/access/brin
parent4bfaea11d2d686a06487c2e33297bf17f12732d7 (diff)
Limit the size of TID lists during parallel GIN build
When building intermediate TID lists during parallel GIN builds, split the sorted lists into smaller chunks, to limit the amount of memory needed when merging the chunks later. The leader may need to keep in memory up to one chunk per worker, and possibly one extra chunk (before evicting some of the data). The code processing item pointers uses regular palloc/repalloc calls, which means it's subject to the MaxAllocSize (1GB) limit. We could fix this by allowing huge allocations, but that'd require changes in many places without much benefit. Larger chunks do not actually improve performance, so the memory usage would be wasted. Fixed by limiting the chunk size to not hit MaxAllocSize. Each worker gets a fair share. This requires remembering the number of participating workers, in a place that can be accessed from the callback. Luckily, the bs_worker_id field in GinBuildState was unused, so repurpose that. Report by Greg Smith, investigation and fix by me. Batchpatched to 18, where parallel GIN builds were introduced. Reported-by: Gregory Smith <gregsmithpgsql@gmail.com> Discussion: https://postgr.es/m/CAHLJuCWDwn-PE2BMZE4Kux7x5wWt_6RoWtA0mUQffEDLeZ6sfA@mail.gmail.com Backpatch-through: 18
Diffstat (limited to 'src/backend/access/brin')
0 files changed, 0 insertions, 0 deletions