Re: [PATCHES] Post-special page storage TDE support

On Mon, Nov 13, 2023 at 2:52 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> > This scheme would open up space per page that would now be available for
> > plenty of other things; the encoding in the header and the corresponding
> > available space in the footer would seem to open up quite a few options
> > now, no?
>
> Sure, if you're willing to rewrite the whole cluster to upgrade and
> willing to
> permanently sacrifice some data density. If the stored data is actually
> specific to the page - that is the place to put the data. If not, then the
> tradeoff is much more complicated IMO.
>
> Of course this isn't a new problem - storing the page size on each page was
> just silly, it's never going to change across the cluster and even more
> definitely not going to change within a single relation.
>

Crazy idea; since stored pagesize is already a fixed cost that likely isn't
going away, what if instead of the pd_checksum field, we instead
reinterpret pd_pagesize_version; 4 would mean "no page features", but
anything 5 or higher could be looked up as an external page feature set,
with storage semantics outside of the realm of the page itself (other than
what the page features code itself needs to know); i.e,. move away from the
on-page bitmap into a more abstract representation of features which could
be something along the lines of what you were suggesting, including
extension support.

It seems like this could also support adding/removing features on page
read/write as long as there was sufficient space in the reserved_page
space; read the old feature set on page read, convert to the new feature
set which will write out the page with the additional/changed format.
Obviously there would be bookkeeping to be done in terms of making sure all
pages had been converted from one format to another, but for the page level
this would be straightforward.

Just thinking aloud here...

David