| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Hannu Krosing <hannuk(at)google(dot)com> |
| Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values, round two |
| Date: | 2026-08-10 00:08:40 |
| Message-ID: | ankWiGFlOL-gn7Hs@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 09, 2026 at 11:53:23PM +0200, Hannu Krosing wrote:
> I understand from some earlier messages that in one of the patches you
> refactored the code to make it easier to add new VARLENA on disk
> types.
(Top-posting?)
> Where should I start looking for this?
Quoting the top message of the thread:
```
The main feedback of the previous thread is that the previous
implementation with its callbacks for each vartag was not liked much,
and their were concerns with pointer redirections and
performance. This patch set uses what I am calling the "brutal"
approach, relying on a vartag_external of a varlena or the atttype of
the TOAST relation to decide which external toast pointer we should
use. This uses no function pointers, and patches the code to deal
with Oid or Oid8 TOAST values where it matters. So, this time,
performance cannot really be an issue.
```
The refactoring worked around a set of callbacks that could be
assigned to specific vartag_external, and one of the feedback that I
got is that this required function pointers, which could impact
performance for bulk-read or bulk-write of TOAST data. This
refactoring is gone as of round two, switching to direct if/elif
block. Overall the result is not that bad, as long as one is aware of
all the code paths that need to be handled on HEAD.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-08-10 00:14:51 | Re: Fetch digests explicitly for cryptohash with OpenSSL 3.0 and later |
| Previous Message | Tom Lane | 2026-08-09 23:53:57 | Re: [PATCH] Fix vacuum_delay_point happening inside lock |