Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHPDP-0003WZ-Rq for pgsql-docs@arkaria.postgresql.org; Mon, 16 Jan 2023 13:07:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pHPDO-00009L-Qt for pgsql-docs@arkaria.postgresql.org; Mon, 16 Jan 2023 13:07:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHPDO-000097-GU for pgsql-docs@lists.postgresql.org; Mon, 16 Jan 2023 13:07:54 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pHPDK-0007rA-5W for pgsql-docs@lists.postgresql.org; Mon, 16 Jan 2023 13:07:54 +0000 Received: by mail-ej1-x62a.google.com with SMTP id cf18so61582000ejb.5 for ; Mon, 16 Jan 2023 05:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=KMWhoQKbaGTkliaOcP766gF2harMrWBxXAKbw0pr4Ac=; b=KgDv+bBwv2YV5UGWxkvItOk5vgnWGxnOnVto+N4hON4eLd94MyAwjJR+Izd286jJw1 JaSvpXG1HRhHeIPhjrlKSzfqnzKa8NTzdR0AAyb3JUpgzh98vpzgtgnRqg1Y8BmO9ETp zjiYCUv46SaZyR2UTPdG7iYnrh+3gejH2VifnOdrqD4B1f4OHHOycjkUltAmAtZ/IaEP JlZqKS2a286qqGMGDMo3esguEKmzDpA8dxMjf1XbkKoSg6/9gf7O4WZVULN7L3m80fQO i+/8m41p0v+Cs7DbKiTgOwmAYB0j7a88P08msBAUGlWZ8wayxTm2UXVo7+lPrfUctPjK lr8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KMWhoQKbaGTkliaOcP766gF2harMrWBxXAKbw0pr4Ac=; b=O6ycH2OZdakoUWxwsbKWSbKQnRBusel6DJC010F9NkYFh1gqqHXQLH6tIr25LMcAiX sojAi25CpRVGAbQXQT4Jx6XxStPGsOAVOwYWh1YQ6LDYDtGCPVkrRbwDcHUjl3A4/SuH 6ozf8tJzo/DiXLBQQde+STFCI8ZnGm/Ouwe2gbRGYPkxfB5al/jGJtFAatjWI4AXztfC ShsVMy0KiK13FEPyP3e4fkdFtPXkEl88AFFIWJ5zkucBwgVSDkLNuNLHh5BtJNl057+k /BGmvK8q4SIqzrtjWQW7ux4NgJnSWwy4C6VAQ5wVF1wTvQDl5DtJMEZHrc4uKpO8pEgJ lzzA== X-Gm-Message-State: AFqh2krpAs21G/fcAxMc3uzLENr5qnQAJ5CrTJOHiLAQruUgGZH6oLcM K6EI23j+Ikec80M+3SCqd0UmPA== X-Google-Smtp-Source: AMrXdXthLwUIWF8InVtxTLOty+NVzts6v/86aSqdP4K5KHvFXs33pT/kMWOrYcZOWjVRbjAxeWy8rg== X-Received: by 2002:a17:906:d052:b0:7c1:5098:907a with SMTP id bo18-20020a170906d05200b007c15098907amr80312019ejb.35.1673874469349; Mon, 16 Jan 2023 05:07:49 -0800 (PST) Received: from localhost.localdomain (62-47-151-167.adsl.highway.telekom.at. [62.47.151.167]) by smtp.gmail.com with ESMTPSA id r1-20020a17090609c100b0084ce5d3afe7sm11727701eje.184.2023.01.16.05.07.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Jan 2023 05:07:48 -0800 (PST) Message-ID: <245d0f085c68fe0b877235d76a7c32a71454f39b.camel@cybertec.at> Subject: Re: The documentation for storage type 'plain' actually allows single byte header From: Laurenz Albe To: Tom Lane Cc: Andres Freund , suchithjn22@gmail.com, pgsql-docs@lists.postgresql.org Date: Mon, 16 Jan 2023 14:07:48 +0100 In-Reply-To: <1698750.1673818827@sss.pgh.pa.us> References: <167336599095.2667301.15497893107226841625@wrigleys.postgresql.org> <1698750.1673818827@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, 2023-01-15 at 16:40 -0500, Tom Lane wrote: > Laurenz Albe writes: > > On Tue, 2023-01-10 at 15:53 +0000, PG Doc comments form wrote: > > > > 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? > > > 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". >=20 > > I think that the documentation is wrong.=C2=A0 The attached patch remov= es the > > offending half-sentence. >=20 > The documentation is correct, what is broken is the code. I see. But what is the reason for that anyway? Why not allow short varlen= a headers if TOAST storage is set to PLAIN? Yours, Laurenz Albe