On Fri, Apr 30, 2021 at 1:28 PM Peter Geoghegan <p...@bowt.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
