Re: problems with making relfilenodes 56-bits

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: problems with making relfilenodes 56-bits
Дата
Msg-id CAH2-Wzk=462Yen49oGPbzPDtTGBF3f=W4TTYn_kW66QVr+nJhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: problems with making relfilenodes 56-bits  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, Sep 30, 2022 at 5:20 PM Andres Freund <andres@anarazel.de> wrote:
> I think it'd be an OK tradeoff to optimize WAL usage for a few of the worst to
> pay off for 56bit relfilenodes. The class of problems foreclosed is large
> enough to "waste" "improvement potential" on this.

I agree overall.

A closely related but distinct question occurs to me: if we're going
to be "wasting" space on alignment padding in certain cases one way or
another, can we at least recognize those cases and take advantage at
the level of individual WAL record formats? In other words: So far
we've been discussing the importance of not going over a critical
threshold for certain WAL records. But it might also be valuable to
consider recognizing that that's inevitable, and that we might as well
make the most of it by including one or two other things.

This seems most likely to matter when managing the problem of negative
compression with per-WAL-record compression schemes for things like
arrays of page offset numbers [1]. If (say) a given compression scheme
"wastes" space for arrays of only 1-3 items, but we already know that
the relevant space will all be lost to alignment needed by code one
level down in any case, does it really count as waste? We're likely
always going to have some kind of negative compression, but you do get
to influence where and when the negative compression happens.

Not sure how relevant this will turn out to be, but seems worth
considering. More generally, thinking about how things work across
multiple layers of abstraction seems like it could be valuable in
other ways.

[1] https://postgr.es/m/CAH2-WzmLCn2Hx9tQLdmdb+9CkHKLyWD2bsz=PmRebc4dAxjy6g@mail.gmail.com
--
Peter Geoghegan



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH v1] [meson] add a default option prefix=/usr/local/pgsql