Caveats from reloption toast_tuple_target

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Caveats from reloption toast_tuple_target
Дата
Msg-id 20190403063759.GF3298@paquier.xyz
обсуждение исходный текст
Ответы Re: Caveats from reloption toast_tuple_target  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.

Thoughts?
--
Michael

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] generated columns
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [PATCH v20] GSSAPI encryption support