Re: MaxOffsetNumber for Table AMs

On Mon, 2021-05-03 at 18:12 -0700, Peter Geoghegan wrote:
> But look at the details: tidbitmap.c uses MaxHeapTuplesPerPage as its
> MAX_TUPLES_PER_PAGE, which seems like a problem -- that's 291 with
> default BLCKSZ. I doubt that that restriction is something that you
> can afford to live with, even just for the time being.

Oh, you're right. I missed that MaxHeapTuplesPerPage was an order of
magnitude smaller.

> I don't see why that's necessarily a problem. Why, in general, should
> every table AM be able to support every index AM?

I didn't propose that every table AM needs to support every index type,
just that we should do something or at least document something. It's
pretty frustrating to have to fall back to manually managing the
indexes for dozens or hundreds of partitions when you make use of
multiple table AMs.

We might be conflating support for index AMs with support for features
like bitmap scans. If a certain kind of index fails at CREATE INDEX
time, that's painful for the partitioning case. But here it's more like
the CREATE INDEX would succeed but it would just never be used, which
is a different kind of frustrating.

Whatever we do or don't do, we should try to avoid surprises. I expect
table AMs to be used heavily with partitioning.

Regards,
Jeff Davis