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
|
Список | 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 по дате отправления: