Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas

On Thu, Apr 7, 2022 at 3:27 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I just meant that it wouldn't be reasonable to impose a fixed cost on
> every user, even those not using the feature. Which you said yourself.

Unfortunately, I think there's bound to be some cost. We can avoid
using the space in the page for every user, but anything that makes
the page layout variable is going to cost some number of CPU cycles
someplace. We have to measure that overhead and see if it's small
enough that we're OK with it.

> I got that much, of course. That will work, I suppose, but it'll be
> the first and last time that anybody gets to do that (unless we accept
> it being incompatible with encryption).

Yeah.

> > If we *didn't* put the nonce at the end of the page, where else would
> > we put it? It has to be at a fixed offset, because otherwise you can't
> > find it without decrypting the page first, which would be circular.
>
> Immediately before the special area proper (say BTOpaque), which would
> "logically come after" the special space under this scheme. You
> wouldn't have a simple constant offset into the page, but you'd have
> something not too far removed from such a constant. It could work as a
> constant with minimal context (just the AM type). Just like with
> Matthias' patch.

I don't think this would work, because I don't think it would be
practical to always know the AM type. Think about applying an XLOG_FPI
record, for example.

--
Robert Haas
EDB: http://www.enterprisedb.com