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

From Michael Paquier
Subject Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
Date
Msg-id Y4VQvu1lLQ2gipls@paquier.xyz
Whole thread Raw
In response to Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
List pgsql-hackers
On Mon, Nov 28, 2022 at 05:31:50PM -0500, Tom Lane wrote:
> After looking through this thread, I side with Robert: we should reject
> the remainder of this patch.  It gives up page layout flexibility that
> we might want back someday.  Moreover, I didn't see any hard evidence
> offered that there's any actual performance gain, let alone such a
> compelling gain that we should give up that flexibility for it.

As far as I understand, we are talking about this one:
https://www.postgresql.org/message-id/CAEze2Wj9c0abW2aRbC8JzOuUdGurO5av6SJ2H83du6tM+Q1rHQ@mail.gmail.com
After a few months looking at it again, I cannot get much excited
about switching these routines from a logic where we look at the page
header to something where we'd rely on the opaque structure size.

I am wondering if it would be worth adding an AssertMacro() like in
this one, though:
https://www.postgresql.org/message-id/YkaP64JvZTMgcHtq@paquier.xyz

This still uses PageGetSpecialPointer() to retrieve the pointer area
from the page header, but it also checks that we have a match with the
structure expected by the index AM.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Tom Lane
Date:
Subject: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas