Re: RFI: Extending the TOAST Pointer

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikita Malakhov <hukutoc(at)gmail(dot)com>
Subject: Re: RFI: Extending the TOAST Pointer
Date: 2023-05-24 00:17:16
Message-ID: ZG1XjI5meIvQNS/+@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 23, 2023 at 12:33:50PM -0400, Robert Haas wrote:
> For projects like this, the details matter a lot. If the goal is to
> add a new compression type that behaves like the existing compression
> types, more or less, then I think we should allocate the last
> ToastCompressionId bit to mean "some other compression ID" and add a
> 1-byte header that says which one is in use. But if the new feature
> being added is enough different from the other compression methods,
> then it might be better to do it in some other way e.g. a new VARTAG.

Agreed. While the compression argument and the possibility to add
more options to toast pointers are very appealing, FWIW, I'd like to
think that the primary target is the 4-byte OID assignment limit of
where backends loop infinitely until a OID can be found, which can be
a real pain for users with a large number of blobs or just enough
toast data to trigger it.

Saying that even if I sent the patch for zstd on toast..
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-05-24 00:31:34 Re: Make pgbench exit on SIGINT more reliably
Previous Message John Naylor 2023-05-23 23:16:54 Re: [PoC] Improve dead tuple storage for lazy vacuum