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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
Дата
Msg-id Y4VQvu1lLQ2gipls@paquier.xyz
обсуждение исходный текст
Ответ на Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Imseih (AWS), Sami"
Дата:
Сообщение: Re: Add index scan progress to pg_stat_progress_vacuum
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas