On Tue, Jun 14, 2022 at 3:25 PM Peter Geoghegan <p...@bowt.ie> wrote: > I am proposing that we not commit ourselves to relying on implicit > information about what must be true for every page in the cluster. > Just having a little additional page-header metadata (in pd_flags) > would accomplish that much, and wouldn't in itself impose any real > overhead on TDE. > > It's not like the PageHeaderData.pd_flags bits are already a precious > commodity, in the same way as the heap tuple infomask status bits are. > We can afford to use some of them for this purpose, and then some. > > Why wouldn't we do it that way, just on general principle? > > You may still find it useful to rely on high level context at the > level of code that runs on the server, perhaps for performance reasons > (though it's unclear how much it matters). In which case the status > bit is technically redundant information as far as the code is > concerned. That may well be fine.
I still am not clear on precisely what you are proposing here. I do agree that there is significant bit space available in pd_flags and that consuming some of it wouldn't be stupid, but that doesn't add up to a proposal. Maybe the proposal is: figure out how many different configurations there are for this new kind of page space, let's say N, and then reserve ceil(log2(N)) bits from pd_flags to indicate which one we've got. One possible problem with this is that, if the page is actually encrypted, we might want pd_flags to also be encrypted. The existing contents of pd_flags disclose some information about the tuples that are on the page, so having them exposed to prying eyes does not seem appealing. -- Robert Haas EDB: http://www.enterprisedb.com
