Re: BTScanOpaqueData size slows down tests

Peter Geoghegan <pg(at)bowt(dot)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