MIME-Version: 1.0
References: <CAKna9VbQ=o2Yhjo1EitaxzYpWAXe9vw6QtamzCsNNp2-rQOFSA@mail.gmail.com>
 <CAKFQuwYpai5snt5mEgyXK4m6nR5T6sP-YTYH-GQ0Hs2rXS7uLA@mail.gmail.com>
 <CAKna9VZdihb=n9mNGaCZLKYbWAoS0+knfi_PAfLC5w=Mj5Egig@mail.gmail.com>
 <D4CAF64D-2F47-470B-9F14-860FFD7FD2E7@gmail.com> <CAKna9VaNKPR9XruS-yz0qLLgAyik6L-_kGX=C8B682wRSmnn=A@mail.gmail.com>
 <A306FFC9-1D69-4C3F-8B4D-F0983D9E9C33@gmail.com> <CAKna9VYXKu-1KpV_1X3Jz0iNZ+Uf4WGwYRm62tCQvyp4-L0WCw@mail.gmail.com>
 <CAApHDvp6FJW0MnchEfis=2ANUTNu4CHVQOcs95=NwTg4SQrxtQ@mail.gmail.com>
In-Reply-To: <CAApHDvp6FJW0MnchEfis=2ANUTNu4CHVQOcs95=NwTg4SQrxtQ@mail.gmail.com>
From: Lok P <loknath.73@gmail.com>
Date: Fri, 5 Jul 2024 14:23:17 +0530
Message-ID: <CAKna9Vah53TtUX9qYpDz0hPoAFSLUBqtzriWU=xy8vCWQU+Leg@mail.gmail.com>
Subject: Re: Design strategy for table with many attributes
To: David Rowley <dgrowleyml@gmail.com>
Cc: Guyren Howe <guyren@gmail.com>, pgsql-general <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000085f39f061c7c322b"
Archived-At: <https://www.postgresql.org/message-id/CAKna9Vah53TtUX9qYpDz0hPoAFSLUBqtzriWU%3Dxy8vCWQU%2BLeg%40mail.gmail.com>
Precedence: bulk

--00000000000085f39f061c7c322b
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Jul, 2024, 1:44 pm David Rowley, <dgrowleyml@gmail.com> wrote:

> On Fri, 5 Jul 2024 at 19:53, Lok P <loknath.73@gmail.com> wrote:
> > As David suggested it breaks if a row exceeds the 8k limit I. E a single
> page size , will that still holds true if we have a column with JSON in it?
>
> You wouldn't be at risk of the same tuple length problem if you
> reduced the column count and stored the additional details in JSON.
> Each varlena column is either stored in the tuple inline, or toasted
> and stored out of line. Out of line values need an 18-byte pointer to
> the toasted data. That pointer contributes to the tuple length.
>
>
> David
>

Got it. Thank you very much.

So there would be performance overhead with JSON and we need to validate
that carefully, if at all going in that direction.

However out of curiosity, if the roasted/compressed component or column
which is JSON itself goes beyond 8k post compression, will it break then?

--00000000000085f39f061c7c322b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"><br></div><div><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 5 Jul, 2024, 1:44 pm David=
 Rowley, &lt;<a href=3D"mailto:dgrowleyml@gmail.com">dgrowleyml@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 5 Jul 2024 at=
 19:53, Lok P &lt;<a href=3D"mailto:loknath.73@gmail.com" target=3D"_blank"=
 rel=3D"noreferrer">loknath.73@gmail.com</a>&gt; wrote:<br>
&gt; As David suggested it breaks if a row exceeds the 8k limit I. E a sing=
le page size , will that still holds true if we have a column with JSON in =
it?<br>
<br>
You wouldn&#39;t be at risk of the same tuple length problem if you<br>
reduced the column count and stored the additional details in JSON.<br>
Each varlena column is either stored in the tuple inline, or toasted<br>
and stored out of line. Out of line values need an 18-byte pointer to<br>
the toasted data. That pointer contributes to the tuple length.<br><br>
<br>
David<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div dir=3D"auto">Got it. Thank you very much.=C2=A0</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">So there would be performance overhead wi=
th JSON and we need to validate that carefully, if at all going in that dir=
ection.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">However ou=
t of curiosity, if the roasted/compressed component or column which is JSON=
 itself goes beyond 8k post compression, will it break then?=C2=A0</div></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--00000000000085f39f061c7c322b--