On Tue, Jun 14, 2022 at 3:25 PM Peter Geoghegan <pg@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