Peter Geoghegan <p...@bowt.ie> writes: > It isn't at all rare for the scan to have to return about 1350 TIDs > from a page, though. Any low cardinality index will tend to have > almost that many TIDs to return on any page that only stores > duplicates. And scan will necessarily have to return all of the TIDs > from such a page, if it has to return any.
Agreed, but scans that just return one item are also very common, particularly in the syscache-miss case that Andres started with. I could get behind the idea of just having enough space in BTScanOpaqueData for about ten items, and dynamically allocating a MaxTIDsPerBTreePage-sized array only if we overrun that. And not allocate any space for mark/restore unless a mark is done. regards, tom lane