Re: Support for 8-byte TOAST values, round two - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for 8-byte TOAST values, round two
Date
Msg-id aqnkDNytpMUrsTfi@paquier.xyz
Whole thread
In response to Re: Support for 8-byte TOAST values, round two  ("Greg Burd" <greg@burd.me>)
List pgsql-hackers
On Tue, Sep 15, 2026 at 01:05:09PM -0400, Greg Burd wrote:
> Pinning default_toast_compression in the test would work too, though it costs
> you the coverage of whichever method you did not pin.

Using default_toast_compression is perhaps nicer (same as
portals.sql).  It offers more predictibility in the output and we
don't really care about the compression method in this case.  The md5
computations can be more expensive, which I find annoying, so I'm
eager to just reuse the smart pattern of toast.sql instead.  It's much
cheaper, and enforces the out-of-line behavior we want here.

Note: test_decoding has the same issue.  Oops.  Will fix in a bit
after more checks.

> Either way this is Michael's call to make, I'm anxious to hear his thoughts
> on this.

Replied to that upthread, as of:
https://www.postgresql.org/message-id/aqni9bvWV0UIUEZy@paquier.xyz

I don't think that this new reloption should equal in expectations
with fillfactor and/or tuple_toast_target.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for 8-byte TOAST values, round two
Next
From: Richard Guo
Date:
Subject: Re: remove_useless_joins vs. bug #19560