Re: MaxOffsetNumber for Table AMs

On Fri, Apr 30, 2021 at 1:28 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Global indexes should work by adding an extra column that is somewhat
> like a TID, that may even have its own pg_attribute entry. It's much
> more natural to make the partition number a separate column IMV --
> nbtree suffix truncation and deduplication can work in about the same
> way as before. Plus you'll need to do predicate pushdown using the
> partition identifier in some scenarios anyway. You can make the
> partition identifier variable-width without imposing the cost and
> complexity of variable-width TIDs on index AMs.

I agree up to a point but ... are you imagining that the TID continues
to have its own special place in the page, while the partition
identifier is stored more like a regular tuple column? Because it
seems to me that it would be better to try to eliminate the
special-storage case, just like we did for OIDs. If you want a 6-byte
TID, put a 6-byte column in the tuple for it. If you also want a
partition identifier, put an extra column in the tuple for that. If
you want a wider TID or a varlena TID, well, put columns for that into
the tuple instead of the 6-byte column you'd normally put. This seems
extremely flexible and a lot more aesthetically appealing than what we
have today.

--
Robert Haas
EDB: http://www.enterprisedb.com