Re: MaxOffsetNumber for Table AMs
От | Robert Haas |
---|---|
Тема | Re: MaxOffsetNumber for Table AMs |
Дата | |
Msg-id | CA+TgmoZR2_nUQPNOgBSa6o70vM61mQ8fxJ0VdueRfK1QCrFHJw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MaxOffsetNumber for Table AMs (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: MaxOffsetNumber for Table AMs
|
Список | pgsql-hackers |
On Fri, Apr 30, 2021 at 1:28 PM Peter Geoghegan <pg@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
В списке pgsql-hackers по дате отправления: