Re: Caveats from reloption toast_tuple_target

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Caveats from reloption toast_tuple_target
Дата
Msg-id CA+TgmobsWaG1p+snDO8+sZj9SnDeAozp4oxz6A7KYftdNAi5yg@mail.gmail.com
обсуждение исходный текст
Ответ на Caveats from reloption toast_tuple_target  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Caveats from reloption toast_tuple_target  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Apr 3, 2019 at 2:38 AM Michael Paquier <michael@paquier.xyz> wrote:
> Hi all,
> (Adding Simon as the author of toast_tuple_target, as well Andrew and
> Pavan in CC.)
>
> toast_tuple_target has been introduced in 2017 by c251336 as of v11.
> And while reviewing Pavan's patch to have more complex control over
> the compression threshold of a tuple, I have bumped into some
> surprising code:
> https://www.postgresql.org/message-id/20190403044916.GD3298@paquier.xyz
>
> As far as I understand it, even with this option we don't try to toast
> tuples in heap_prepare_insert() and heap_update() where
> TOAST_TUPLE_THRESHOLD gets used to define if a tuple can be toasted or
> not.  The same applies to raw_heap_insert() in rewriteheap.c, and
> needs_toast_table() in toasting.c.
>
> Shouldn't we use the reloption instead of the compiled threshold to
> determine if a tuple should be toasted or not?  Perhaps I am missing
> something?  It seems to me that this is a bug that should be
> back-patched, but it could also be qualified as a behavior change for
> existing relations.

Could you explain a bit more clearly what you think the bug is?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_basebackup ignores the existing data directory permissions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: partitioned tables referenced by FKs