Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
Date
Msg-id CAH2-WzmOwgmJrtW0=H2kitqc7fjRSnd98aHcW4KKh6W_XEoodg@mail.gmail.com
Whole thread Raw
In response to Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Apr 7, 2022 at 12:37 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Apr 7, 2022 at 3:27 PM Peter Geoghegan <pg@bowt.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 wouldn't go so far as to say that any non-zero overhead is not okay
(that sounds really extreme). I would only say this much: wasting
non-trivial amounts of space on every page must not happen. If the
user opts-in to the feature then it's not just waste, so that's
perfectly okay. (I imagine that we agree on this much already.)

> > 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.

There are already some pretty shaky heuristics that are used by tools
like pg_filedump for this exact purpose. But they work! And they're
even supported by Postgres, quasi-officially -- grep for "pg_filedump"
to see what I mean.

There are numerous reasons why we might want to put that on a formal
footing, so that we can reliably detect the AM type starting from only
a page image. I suspect that you're going to end up needing to account
for this index AMs anyway, so going this way isn't necessarily making
your life all that much harder. (I am not really sure about that,
though, since I don't have enough background information.)


--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Mingw task for Cirrus CI
Next
From: Stephen Frost
Date:
Subject: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas