Re: MaxOffsetNumber for Table AMs

On Tue, 2021-05-04 at 13:51 -0700, Peter Geoghegan wrote:
> I think maybe it is possible for GIN to work with your column store
> table AM in particular. Why aren't we talking about that concrete
> issue, or something like that?

Happy to.

At this point I'd rather obey the constraint that the offset number
falls in the range [1, MaxHeapTuplesPerPage] so that columnar will have
bitmap index scans and GIN. If you see a way to work around this
limitation and still have GIN and bitmap index support, so much the
better.

The cost of obeying this limitation is that, in a workload involving
lots of small transactions, columnar might run out of TID space and
force a VACUUM FULL. In that case, VACUUM FULL is probably a good idea
anyway (to coalesce the tuples for better compression), but forcing it
is obviously not ideal. The reason columnar will run out of TID space
more quickly for small operations is because small inserts might
reserve more TIDs then they actually use, leaving gaps; and small
updates/deletes will fragment the TID space.

The benefit of obeying this limitation is that I expect that bitmap
index scans will work well with columnar because they avoid random
access. And it seems like a nice benefit if we can support the full
range of index AMs for columnar.

> I don't get what the point of this patch is. Obviously all of the
> particulars here are just accidents of history that we ought to
> change
> sooner or later anyway.

The point is if "sooner" turns into "later" then we at least have some
guidance for table AM authors in the interim. But if nobody else thinks
that's useful, then so be it.

Regards,
Jeff Davis