| From: | Nikhil Kumar Veldanda <veldanda(dot)nikhilkumar17(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Burd, Greg" <greg(at)burd(dot)me>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |
| Date: | 2025-11-26 07:09:00 |
| Message-ID: | CAFAfj_GHDjGcSQoT-xdWUK6ASWW4Je_1gFZC=snPC-oSB4w7Jw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Michael,
On Tue, Nov 25, 2025 at 8:54 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > Tom, you are registered as a reviewer of the patch. The point of
> > contention of the patch, where I see there is no consensus yet, is if
> > my approach of using a redirection for the external TOAST pointers
> > with a new layer to facilitate the addition of more vartags (aka the
> > 64b value vartag proposed here, concept that could also apply to
> > compression methods later on) is acceptable. Moving to a different
> > approach, like the "brutal" one I am naming upthread where the
> > redirection layer is replaced by changes in all the code paths that
> > need to be touched, would be of course cheaper at runtime as there
> > would be no more redirection, but the maintenance would be a nightmare
> > the more vartags we add, and I have some plans for more of these.
> > Doing the switch would be a few hours work, so that would not be a big
> > deal, I guess. The important part is an agreement about the approach,
> > IMO.
>
> This point still got no reply. It would be nice to do something for
> this release regarding this old issue, IMO..
> --
Thanks for the updated v8. I’m also looking forward to feedback on the
vartag approach. My work on adding ZSTD compression depends on this
design decision, so consensus here will help me proceed in the right
direction.
--
Nikhil Veldanda
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2025-11-26 07:13:26 | Re: How can end users know the cause of LR slot sync delays? |
| Previous Message | Arseniy Mukhin | 2025-11-26 07:00:31 | Re: [PATCH] Avoid pallocs in async.c's "critical section" |