Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 1 Oct 2026 08:22:22 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Hannu Krosing <hannuk@google.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	John Naylor <johncnaylorls@gmail.com>, Greg Burd <greg@burd.me>,
	Yugo Nagata <nagata@sraoss.co.jp>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Support for 8-byte TOAST values, round two
Message-ID: <ar2ZrnIR6OC14ppI@paquier.xyz>
References: 
 <CALj2ACVCicT3mWFD4Y-QsR+67THZ8J3FPmFtpTns2JxG3udGUQ@mail.gmail.com>
 <aqd_gYs35v--sVlR@paquier.xyz>
 <CALj2ACVLbSB1L+ObOhXE_ZS3ZVu50Cm-BsM5AGcc4grnO_F5JQ@mail.gmail.com>
 <aqju1K96ex28yz2X@paquier.xyz>
 <CANWCAZa+pWZL1Zjep1pz1F0sVWwNOQf+QfGErOaiUvC10Yr2XA@mail.gmail.com>
 <CALj2ACUdXAngMaoPD_EFCPDha8AnqFwBmO8bOUgkucYOuYmf4w@mail.gmail.com>
 <arI1As2FmhTYSaYZ@paquier.xyz>
 <CALj2ACW1+23ikei=sB3EMV44EOE-vbbMA_dSXSOkOhj9QNVuUQ@mail.gmail.com>
 <arOwskPgH8djIszw@paquier.xyz>
 <CAMT0RQSEvkAEXPtnWzuzQZovYscjQUeiVsSv_QfLQirdWuQ3wg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Xc55UVNU6ng6SKkv"
Content-Disposition: inline
In-Reply-To: 
 <CAMT0RQSEvkAEXPtnWzuzQZovYscjQUeiVsSv_QfLQirdWuQ3wg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ar2ZrnIR6OC14ppI%40paquier.xyz>
Precedence: bulk

--Xc55UVNU6ng6SKkv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 30, 2026 at 12:44:28PM +0200, Hannu Krosing wrote:
> In my insert tests 8-byte TOAST was much faster that 4-byte toast
>=20
> This resulted in a solid 23% speed-up because it didn't need to verify
> new OIDs against the unique index, despite each toast index entry
> taking up slightly more space (30.1 bytes vs. 21.4 bytes on average)

The speedup is not surprising.  Thanks for posting some numbers.

A note about that.  Postgres hackers had a meetup two weeks ago in
Tokyo where I have reported the activity of this thread, including the
fact that the new values are not rechecked in the INSERT path.

My opinion, same as upthread, is that a recheck is kind of pointless
because we should never go backwards under normal running conditions
and we would run out of LSNs before we reach the OID8 limit.  I did
mention the argument of using pg_resetwal -o to go backwards, leading
to INSERT failures due to duplicates of the TOAST unique index.
Fujii-san had a more biased opinion than mine, mentioning that a
recheck could be a more defensive position, even if it costs in normal
running conditions.

Perhaps my opinion will be overruled in this release cycle, which is
fine, I just want to point out that the API toastid_valueid_exists()
is transparently able to work with a recheck of Oid8 values, so the
value recheck could be plugged in for this case as well, depending on
how the discussion flows.  Perhaps there is a bug I am not aware of
yet, that could justify the recheck, of course.
--
Michael

--Xc55UVNU6ng6SKkv
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmq9ma4ACgkQnvQgOdby
QH2WVw//Zn6sViLEu+/eC8ek7RGGKDlmuoAuuwSgfL+GeFE49UMO9srhumIb5cMx
gNbQYkuHxLcFrwgz/pZ7CidpkkZ14S/tx2UnsEAAUG07nE9yOWykPSBGSDa4GVuW
1T/Cq/4rvm9Si8qPR3Uip6DPdmjT/DeDo+CwtJRYYRVM/gP8X6g7tMs0onB8Y2iW
VMSubBCNeSa2CqvbG976lLawiZcvKEvnlMwOUtzC5VB7/nSvbWWKafbLz5YRr9/8
ijUxiQZnKBJZOQGQ5cdzJkRg+TQIfoVVwdSRi/su8rObh8YxI0BbYzv/QP+e9Pwr
8YZ6RjQ0/jeqNb6blBS2UL0BhQo2GoBuKICdK3FGEAuB2mXM0+Scvi2VV+rUpauJ
RKhrTBFvZZuGQE/YelpoBOkvSEoljtkE7EVtE/twr5t/aAJT692dMTU7R6AjvSnr
3AbwRgo2655kmwzJOzCmp400Uvu+gTuk8w3xk6lQCca59yyx3q/AR0lUPMG0SryR
65w9UShhOwPp7iYIhTuDxwcNNATVADpcIMGjbvjf4VGKIHrEwPEoBPWhE40UqZdZ
OQBM+GriEz1ydpW16CF7izT30x1S7bOlLYEf+rGHzkl3su70qjL/efyw9XMlbQtm
zPzaOEBbqg0EpRTD6PpxS3gaIlV0RB8SD17sE/kJaGM8chaJXrE=
=99Mv
-----END PGP SIGNATURE-----

--Xc55UVNU6ng6SKkv--