Re: MaxOffsetNumber for Table AMs

On Mon, 3 May 2021 at 20:43, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Mon, May 3, 2021 at 10:57 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > For the purposes of this discussion, what's making my life difficult is
> > that we don't have a good definition for TID, leaving me with two
> > options:
> >
> > 1. be overly conservative, accept MaxOffsetNumber=2048, wasting a
> > bunch of address space; or
>
> tidbitmap.c uses MaxHeapTuplesPerPage as its MAX_TUPLES_PER_PAGE,
> which is much lower than MaxOffsetNumber (it's almost 10x lower). I
> wonder what that means for your design.

One could relatively easily disable bitmap scans on the table AM by
not installing the relevant bitmap support functions on the registered
TableAM structure, and thus not touch that problem. Some indexes will
then never be accessed due to the bitmap scan requirement of their
IndexAM (gin, brin, bloom, to name a few), and as such won't make
sense to create on that table, but that's about it I think. We might
want to add some safeguards that bitmapscan-only indexams arent used
on tableams that don't support it, but I believe that's a nice-to-have
and not critical, on a similar level to the deduplication of constaint
indexes.

With regards,

Matthias van de Meent