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