Message-ID: <d99b3e0beebdde0741d28035aaea7f4af56fa050.camel@cybertec.at>
Subject: Re: The documentation for storage type 'plain' actually allows
 single byte header
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: suchithjn22@gmail.com, pgsql-docs@lists.postgresql.org
Date: Thu, 12 Jan 2023 15:43:57 +0100
In-Reply-To: 
 <167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
References: 
	<167336599095.2667301.15497893107226841625@wrigleys.postgresql.org>
Content-Type: multipart/mixed; boundary="=-1Sbh6iU0IKorMAapjCxh"
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/d99b3e0beebdde0741d28035aaea7f4af56fa050.camel%40cybertec.at>
Precedence: bulk

--=-1Sbh6iU0IKorMAapjCxh
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 t=
he
> development version.
>=20
> > PLAIN prevents either compression or out-of-line storage; furthermore i=
t
> > 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" repeated=
 10
> times also indicates character A (65 or 0x41 in ASCII) repeated 10 times.
>=20
> So....This does **not** disable 1-B header. That sentence should be remov=
ed
> from the documentation unless this is a bug.

I think that the documentation is wrong.  The attached patch removes the
offending half-sentence.

Yours,
Laurenz Albe

--=-1Sbh6iU0IKorMAapjCxh
Content-Disposition: attachment;
 filename="0001-Fix-documentation-for-STORAGE-PLAIN.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch;
 name="0001-Fix-documentation-for-STORAGE-PLAIN.patch";
	charset="UTF-8"

RnJvbSA1YmYwYjQzZmU3MzM4NGEyMWY1OWQ5YWQxZjdhOGQ3Y2JjODFmOGM0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5h
dD4KRGF0ZTogVGh1LCAxMiBKYW4gMjAyMyAxNTo0MTo1NiArMDEwMApTdWJqZWN0OiBbUEFUQ0hd
IEZpeCBkb2N1bWVudGF0aW9uIGZvciBTVE9SQUdFIFBMQUlOCgpDb21taXQgM2UyM2I2OGRhYzAs
IHdoaWNoIGludHJvZHVjZWQgc2luZ2xlLWJ5dGUgdmFybGVuYSBoZWFkZXJzLAphZGRlZCBkb2N1
bWVudGF0aW9uIHRoYXQgU1RPUkFHRSBQTEFJTiB3b3VsZCBwcmV2ZW50IHN1Y2ggc2luZ2xlLWJ5
dGUKaGVhZGVycy4gIFRoaXMgaGFzIG5ldmVyIGJlZW4gdHJ1ZS4KLS0tCiBkb2Mvc3JjL3NnbWwv
c3RvcmFnZS5zZ21sIHwgNCArLS0tCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDMg
ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZG9jL3NyYy9zZ21sL3N0b3JhZ2Uuc2dtbCBiL2Rv
Yy9zcmMvc2dtbC9zdG9yYWdlLnNnbWwKaW5kZXggZTViOWYzZjFmZi4uNDc5NWE0ODVkMCAxMDA2
NDQKLS0tIGEvZG9jL3NyYy9zZ21sL3N0b3JhZ2Uuc2dtbAorKysgYi9kb2Mvc3JjL3NnbWwvc3Rv
cmFnZS5zZ21sCkBAIC00NTYsOSArNDU2LDcgQEAgZm9yIHN0b3JpbmcgPGFjcm9ueW0+VE9BU1Q8
L2Fjcm9ueW0+LWFibGUgY29sdW1ucyBvbiBkaXNrOgogICAgIDxsaXN0aXRlbT4KICAgICAgPHBh
cmE+CiAgICAgICA8bGl0ZXJhbD5QTEFJTjwvbGl0ZXJhbD4gcHJldmVudHMgZWl0aGVyIGNvbXBy
ZXNzaW9uIG9yCi0gICAgICBvdXQtb2YtbGluZSBzdG9yYWdlOyBmdXJ0aGVybW9yZSBpdCBkaXNh
YmxlcyB1c2Ugb2Ygc2luZ2xlLWJ5dGUgaGVhZGVycwotICAgICAgZm9yIHZhcmxlbmEgdHlwZXMu
Ci0gICAgICBUaGlzIGlzIHRoZSBvbmx5IHBvc3NpYmxlIHN0cmF0ZWd5IGZvcgorICAgICAgb3V0
LW9mLWxpbmUgc3RvcmFnZS4gIFRoaXMgaXMgdGhlIG9ubHkgcG9zc2libGUgc3RyYXRlZ3kgZm9y
CiAgICAgICBjb2x1bW5zIG9mIG5vbi08YWNyb255bT5UT0FTVDwvYWNyb255bT4tYWJsZSBkYXRh
IHR5cGVzLgogICAgICA8L3BhcmE+CiAgICAgPC9saXN0aXRlbT4KLS0gCjIuMzkuMAoK


--=-1Sbh6iU0IKorMAapjCxh--