Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)
| От | Nikita Malakhov |
|---|---|
| Тема | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |
| Дата | |
| Msg-id | CAN-LCVOmVUAGrFNcSNzK3vwQ==XuYvEZ5ywwk=Z11CEk-bpVDw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
Hi!
Michael, I'm looking into your patch set for Sequence AMs.
I'm not very happy with single global OID counter for TOAST
tables, so I've decided to investigate your work on sequences
and try to adapt it to TOAST tables. Would report my progress.
Some time ago I've proposed individual TOAST counter
to get rid of table lookups for unused ID, but later decided
that neither reloptions nor pg_class are not a good place
to store it due to lots of related catalog updates including
locks, so sequences look much more useful for this,
as you wrote above.
Personally I'm not too happy with
toast_external_infos[TOAST_EXTERNAL_INFO_SIZE]
array and for me it seems that lookups using VARTAG
should be straightened out with more error-proof, currently
using wrong vartags would result in core dumps.
On Sat, Aug 9, 2025 at 10:40 AM Michael Paquier <michael@paquier.xyz> wrote:
For the 4-byte vs 8-byte value case, I was wondering if we should be
simpler and less optimistic and assume that we are only going to use
the wider one depending on the type of chunk_id in the TOAST table, as
a minimum threshold when checking if a tuple should be toasted or not.
Perhaps my vision of things is too simple, but I cannot think about a
good reason that would justify making this code more complicated than
it already is.
--
Michael
В списке pgsql-hackers по дате отправления: