MIME-Version: 1.0
References: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
 <CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
 <CAMLfE0MWqALMJ99dpFniZ1xknCgHj4ETPWro+Ry9awPUG1OKMw@mail.gmail.com>
 <CAHyXU0y2gZfH_ZomazQB7H0KkuyV3QofvuvZcSYXEhpotG=hMA@mail.gmail.com>
 <CALL-XeM=0oH=2ECawmyCOv2umKF1nyqr97CuQXiPfO39uhCucQ@mail.gmail.com>
 <CAMLfE0O5YPhrXOWP1pLTLHy-rKDut5cmiGyuxo3d43LCGEkJYg@mail.gmail.com>
 <d8788871-38f6-4fe6-8568-c849618bfda6@aklaver.com> <CAMLfE0NMosrY6__P-PVbV3yCLh1Gp1jWpqAm3oJ=PS3mh97oNg@mail.gmail.com>
In-Reply-To: <CAMLfE0NMosrY6__P-PVbV3yCLh1Gp1jWpqAm3oJ=PS3mh97oNg@mail.gmail.com>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Wed, 10 Sep 2025 11:11:30 -0400
Message-ID: <CANzqJaBMExaKVMnMWBDxR=iYcm=ofjpJp6KWkSXijhDU2g8NNg@mail.gmail.com>
Subject: Re: MVCC and all that...
To: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000008bb61d063e73d63f"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaBMExaKVMnMWBDxR%3DiYcm%3DofjpJp6KWkSXijhDU2g8NNg%40mail.gmail.com>
Precedence: bulk

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

On Wed, Sep 10, 2025 at 11:08=E2=80=AFAM Ellen Allhatatlan <
ellenallhatatlan@gmail.com> wrote:
[snip]

> So, you have table X - it has 2M rows (say, 0.5 GB) in the first file
> (along with all the other tables). The 2GB limit is hit, more data is
> added. 0.7 GB is added to table X - these records go into a new
> database file - the table is split in two - you have 2 "extents" of
> 2GB with X split 0.5 - in extent1, 0.7 in extent2. All mixed up with
> other tables as well!
>
> That was the architectural flaw to which I was referring. Nothing to
> do with PG
>

You're gonna be in for a very rude surprise after adding 1GB of data to a
PG table...

--=20
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

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

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Sep 10, 2025 at 11:08=E2=80=AFAM =
Ellen Allhatatlan &lt;<a href=3D"mailto:ellenallhatatlan@gmail.com">ellenal=
lhatatlan@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quo=
te_container"><div>[snip]=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">So, you have table X - it has 2M rows (say, 0.5 GB) in the firs=
t file<br>
(along with all the other tables). The 2GB limit is hit, more data is<br>
added. 0.7 GB is added to table X - these records go into a new<br>
database file - the table is split in two - you have 2 &quot;extents&quot; =
of<br>
2GB with X split 0.5 - in extent1, 0.7 in extent2. All mixed up with<br>
other tables as well!<br>
<br>
That was the architectural flaw to which I was referring. Nothing to<br>
do with PG<br></blockquote><div>=C2=A0</div><div>You&#39;re gonna be in for=
 a very rude surprise after adding 1GB of data to a PG table...=C2=A0</div>=
</div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><br><=
div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Death to &lt;Red=
acted&gt;, and butter sauce.<div>Don&#39;t boil me, I&#39;m still alive.<br=
><div><div>&lt;Redacted&gt; lobster!</div></div></div></div></div></div>

--0000000000008bb61d063e73d63f--