Message-ID: <4977c12e127250fe9777ae57f6f5884b8f5c84ae.camel@cybertec.at>
Subject: Re: The documentation for storage type 'plain' actually allows
 single byte header
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Bruce Momjian <bruce@momjian.us>
Cc: suchithjn22@gmail.com, pgsql-docs@lists.postgresql.org
Date: Sat, 30 Sep 2023 00:35:00 +0200
In-Reply-To: <ZRdNjrI6lUQbD90Y@momjian.us>
References: 
	<167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
	 <d99b3e0beebdde0741d28035aaea7f4af56fa050.camel@cybertec.at>
	 <ZRdNjrI6lUQbD90Y@momjian.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/4977c12e127250fe9777ae57f6f5884b8f5c84ae.camel%40cybertec.at>
Precedence: bulk

On Fri, 2023-09-29 at 18:19 -0400, Bruce Momjian wrote:
> On Thu, Jan 12, 2023 at 03:43:57PM +0100, Laurenz Albe wrote:
> > On Tue, 2023-01-10 at 15:53 +0000, PG Doc comments form wrote:
> > > https://www.postgresql.org/docs/devel/storage-toast.html=C2=A0- This =
is the
> > > development version.
> > >=20
> > > > PLAIN prevents either compression or out-of-line storage; furthermo=
re it
> > > > disables use of single-byte headers for varlena types. This is the =
only
> > > > possible strategy for columns of non-TOAST-able data types.
> > >=20
> > > However, it does allow "single byte" headers. How to verify this?
> > >=20
> > > CREATE EXTENSION pageinspect;
> > > CREATE TABLE test(a VARCHAR(10000) STORAGE PLAIN);
> > > INSERT INTO test VALUES (repeat('A',10));
> > >=20
> > > Now peek into the page with pageinspect functions
> > >=20
> > > SELECT left(encode(t_data, 'hex'), 40) FROM
> > > heap_page_items(get_raw_page('test', 0));
> > >=20
> > > This returned value of "1741414141414141414141".
> > > Here the first byte 0x17 =3D 0001 0111 in binary.
> > > Length + 1 is stored in the length bits (1-7). So Len =3D 0001011-1 =
=3D (11-1)
> > > [base-10] =3D 10 [base-10]
> > > which exactly matches the expected length. Further the data "41" repe=
ated 10
> > > times also indicates character A (65 or 0x41 in ASCII) repeated 10 ti=
mes.
> > >=20
> > > So....This does **not** disable 1-B header. That sentence should be r=
emoved
> > > from the documentation unless this is a bug.
> >=20
> > I think that the documentation is wrong.=C2=A0 The attached patch remov=
es the
> > offending half-sentence.
> >=20
> > Yours,
> > Laurenz Albe
>=20
> > From 5bf0b43fe73384a21f59d9ad1f7a8d7cbc81f8c4 Mon Sep 17 00:00:00 2001
> > From: Laurenz Albe <laurenz.albe@cybertec.at>
> > Date: Thu, 12 Jan 2023 15:41:56 +0100
> > Subject: [PATCH] Fix documentation for STORAGE PLAIN
> >=20
> > Commit 3e23b68dac0, which introduced single-byte varlena headers,
> > added documentation that STORAGE PLAIN would prevent such single-byte
> > headers.=C2=A0 This has never been true.
> > ---
> > =C2=A0doc/src/sgml/storage.sgml | 4 +---
> > =C2=A01 file changed, 1 insertion(+), 3 deletions(-)
> >=20
> > diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
> > index e5b9f3f1ff..4795a485d0 100644
> > --- a/doc/src/sgml/storage.sgml
> > +++ b/doc/src/sgml/storage.sgml
> > @@ -456,9 +456,7 @@ for storing <acronym>TOAST</acronym>-able columns o=
n disk:
> > =C2=A0=C2=A0=C2=A0=C2=A0 <listitem>
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <para>
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <literal>PLAIN</literal> prevents =
either compression or
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 out-of-line storage; furthermore it dis=
ables use of single-byte headers
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for varlena types.
> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is the only possible strategy for
> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 out-of-line storage.=C2=A0 This is the =
only possible strategy for
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 columns of non-<acronym>TOAST</acr=
onym>-able data types.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </para>
> > =C2=A0=C2=A0=C2=A0=C2=A0 </listitem>
> > --=20
> > 2.39.0
> >=20
>=20
> Where did we end with this?=C2=A0 Is a doc patch the solution?

I don't think this went anywhere, and a doc patch is not the solution.

Tom has argued convincingly that single-byte headers are an effect of the T=
OAST
system, and that STORAGE PLAIN should disable all effects of TOAST.

So this would need a code patch.

Yours,
Laurenz Albe