From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Subject: | Caveats from reloption toast_tuple_target |
Date: | 2019-04-03 06:37:59 |
Message-ID: | 20190403063759.GF3298@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2019-04-03 06:49:25 | Re: [PATCH v20] GSSAPI encryption support |
Previous Message | Amit Langote | 2019-04-03 06:37:43 | Re: [HACKERS] generated columns |