On Mon, 2021-05-03 at 09:59 -0700, Peter Geoghegan wrote:
> You don't accept any of that, though. Fair enough. I predict that
> avoiding making a hard choice will make Jeff's work here a lot
> harder,
> though.
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
2. risk the mapping between TID and row number could break at any
time
And compounding that, it seems that there's a bug in GIN that doesn't
honor MaxOffsetNumber, so actually neither of the rules above work
either. Instead, I need to use 2047 as the max offset number, which has
no real basis in the postgres design, but I'd be stuck with it for a
long time.
What I'm looking for is:
* A declaration of what the actual maximum valid offset number is,
and that it will be stable enough to use for table AMs for now. (This
maximum valid offset number may or may not be called MaxOffsetNumber,
and may or may not be tied to the maximum number of items that fit on a
page.)
* A confirmation that this GIN behavior is a bug that should be
fixed, now that there are table AMs in existence that need it fixed.
Even if we fix this in v15, we still need some guidance for what table
AMs should do in earlier versions.
If we change the way tuple IDs are represented or the table AM in v15
or beyond, that may require a REINDEX for indexes on some table AMs. As
long as we have some robust way to check that a REINDEX is necessary,
that's fine with me.
Regards,
Jeff Davis
