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
signature.asc
Description: PGP signature
