On Fri, Apr 8, 2022 at 6:17 AM Robert Haas <robertmh...@gmail.com> wrote: > I agree that the value of 291 is pretty much accidental, but it also > seems fairly generous to me. The bigger you make it, the more space > you can waste. I must have missed (or failed to understand) previous > discussions about why raising it would be a good idea.
What do you mean about wasting space? Wasting space on the stack? I can't imagine you meant wasting space on the page, since being able to accomodate more items on each heap page seems like it would be strictly better, barring any unintended weird FSM issues. As far as I know the only real downside to increasing it is the impact on tidbitmap.c. Increasing the number of valid distinct TID values might have a negative impact on performance during bitmap scans, which will need to be managed. However, I don't think that increased stack space usage will be a problem, with a little work. It either won't matter at all (e.g. an array of offset numbers on the stack still won't be very big), or it can be fixed locally where it turns out to matter (like in lazy_scan_prune). We used to routinely use MaxOffsetNumber for arrays of item offset numbers. I cut down on that in the B-Tree code, reducing it to MaxIndexTuplesPerPage (which is typically 407) in a few places. So anything close to our current MaxIndexTuplesPerPage ought to be fine for most individual arrays stored on the stack. -- Peter Geoghegan
