MIME-Version: 1.0
References: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
In-Reply-To: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
Date: Tue, 9 Sep 2025 11:10:49 -0600
Message-ID: <CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
Subject: Re: MVCC and all that...
To: Ellen Allhatatlan <ellenallhatatlan@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000081ce56063e616376"
Archived-At: <https://www.postgresql.org/message-id/CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM%2BAu1jXQpk3MtBvdogw%40mail.gmail.com>
Precedence: bulk

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

On Tue, Sep 9, 2025 at 10:27=E2=80=AFAM Ellen Allhatatlan <
ellenallhatatlan@gmail.com> wrote:

> Reading this article
>
> https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go=
-wrong-
> I'm a bit confused (not the first time...)
>
> In part 1. Differences in MVCC implementation - he's saying that "It=E2=
=80=99s
> not that the PostgreSQL implementation of MVCC is bad =E2=80=94 it=E2=80=
=99s just
> fundamentally different"
>
> But, I thought Firebird had SWEEP instead of VACUUM (how much closer
> can the words be?) and that FB's implementation of MVCC was
> essentially similar.
> Is this correct? Then why is he pointing out the performance diffs
> because of MVCC? I'm puzzled!


Note: your link is wrong, corrected here:

https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go-w=
rong
<https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go-=
wrong->

What the article is driving at is that postgres does not use rollback logs
to handle updated records in the MVCC implementation.  There are absolutely
performance tradeoffs in that decision and, if you do a lot of development
against postgresql, those tradeoffs should influence how you design
databases.  The author then cherry picked the 'worst case' case, large
unconstrained updates.

The article is a bit of a cheezy dig on postgres.  Another example is the
complaint about autonomous transactions with another cherry picked example
to make postgres look back. In the real world, these would not matter much,
and can be worked around (if you want to see my take on how to deal with
it, see here: https://github.com/leaselock/pgasync).

merlin

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">On Tue, Sep 9, 2025 at 1=
0:27=E2=80=AFAM Ellen Allhatatlan &lt;<a href=3D"mailto:ellenallhatatlan@gm=
ail.com" target=3D"_blank">ellenallhatatlan@gmail.com</a>&gt; wrote:</div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Reading this article<br>
<a href=3D"https://firebirdsql.org/migrating-from-firebird-to-postgresql-wh=
at-can-go-wrong-" rel=3D"noreferrer" target=3D"_blank">https://firebirdsql.=
org/migrating-from-firebird-to-postgresql-what-can-go-wrong-</a><br>
I&#39;m a bit confused (not the first time...)<br>
<br>
In part 1. Differences in MVCC implementation - he&#39;s saying that &quot;=
It=E2=80=99s<br>
not that the PostgreSQL implementation of MVCC is bad=E2=80=89=E2=80=94=E2=
=80=89it=E2=80=99s just<br>
fundamentally different&quot;<br>
<br>
But, I thought Firebird had SWEEP instead of VACUUM (how much closer<br>
can the words be?) and that FB&#39;s implementation of MVCC was<br>
essentially similar.<br>
Is this correct? Then why is he pointing out the performance diffs<br>
because of MVCC? I&#39;m puzzled!</blockquote><div><br></div><div>Note: you=
r link is wrong, corrected here:=C2=A0</div><div><br></div><div><a href=3D"=
https://firebirdsql.org/migrating-from-firebird-to-postgresql-what-can-go-w=
rong-" rel=3D"noreferrer" target=3D"_blank">https://firebirdsql.org/migrati=
ng-from-firebird-to-postgresql-what-can-go-wrong</a></div><div><br></div><d=
iv>What the article is driving at is that postgres does not use rollback lo=
gs to handle updated records in the MVCC implementation.=C2=A0 There are ab=
solutely performance tradeoffs in that decision and, if you do a lot of dev=
elopment against postgresql, those tradeoffs should influence how you desig=
n databases.=C2=A0 The author then cherry picked the &#39;worst case&#39; c=
ase, large unconstrained updates.</div><div><br></div><div>The article is a=
 bit of a cheezy dig on postgres.=C2=A0 Another example is the complaint ab=
out autonomous transactions with another cherry picked example to make post=
gres look back. In the real world, these would not matter much, and can be =
worked around (if you want to see my take on how to deal with it, see here:=
=C2=A0<a href=3D"https://github.com/leaselock/pgasync">https://github.com/l=
easelock/pgasync</a>).</div><div><br></div><div>merlin</div></div></div>
</div>

--00000000000081ce56063e616376--