On Tue, Jan 19, 2021 at 2:57 PM Peter Geoghegan <p...@bowt.ie> wrote: > * Maybe it would be better if you just changed the definition such > that "MAXALIGN(SizeofHeapTupleHeader)" became "MAXIMUM_ALIGNOF", with > no other changes? (Some variant of this suggestion might be better, > not sure.) > > For some reason that feels a bit safer: we still have an "imaginary > tuple header", but it's just 1 MAXALIGN() quantum now. This is still > much less than the current 3 MAXALIGN() quantums (i.e. what > MaxHeapTuplesPerPage treats as the tuple header size). Do you think > that this alternative approach will be noticeably less effective > within vacuumlazy.c?
BTW, I think that increasing MaxHeapTuplesPerPage will make it necessary to consider tidbitmap.c. Comments at the top of that file say that it is assumed that MaxHeapTuplesPerPage is about 256. So there is a risk of introducing performance regressions affecting bitmap scans here. Apparently some other DB systems make the equivalent of MaxHeapTuplesPerPage dynamically configurable at the level of heap tables. It usually doesn't matter, but it can matter with on-disk bitmap indexes, where the bitmap must be encoded from raw TIDs (this must happen before the bitmap is compressed -- there must be a simple mapping from every possible TID to some bit in a bitmap first). The item offset component of each heap TID is not usually very large, so there is a trade-off between keeping the representation of bitmaps efficient and not unduly restricting the number of distinct heap tuples on each heap page. I think that there might be a similar consideration here, in tidbitmap.c (even though it's not concerned about on-disk bitmaps). -- Peter Geoghegan