MIME-Version: 1.0
References: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
 <CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
In-Reply-To: <CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
From: Ellen Allhatatlan <ellenallhatatlan@gmail.com>
Date: Tue, 9 Sep 2025 18:57:30 +0100
Message-ID: <CAMLfE0MWqALMJ99dpFniZ1xknCgHj4ETPWro+Ry9awPUG1OKMw@mail.gmail.com>
Subject: Re: MVCC and all that...
To: Merlin Moncure <mmoncure@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAMLfE0MWqALMJ99dpFniZ1xknCgHj4ETPWro%2BRy9awPUG1OKMw%40mail.gmail.com>
Precedence: bulk

> Note: your link is wrong, corrected here:

Extra hyphen - sorry about and thanks for pointing it out!

> What the article is driving at is that postgres does not use rollback log=
s to handle updated records in the MVCC implementation.  There are absolute=
ly performance tradeoffs in that decision and, if you do a lot of developme=
nt against postgresql, those tradeoffs should influence how you design data=
bases.  The author then cherry picked the 'worst case' case, large unconstr=
ained updates.

Hmm... I was wondering about that - even though he stressed that there
was (paraphrasing) no right or wrong - just different design
decisions!

> 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).

OK - so, I was wrong in my original assumption that somehow (and it
wasn't simply because of the phraseology - sweep vs vacuum) I thought
that PG and FB had a similar MVCC implementation vs. Oracle and MySQL
(InnoDB) (and OrioleDB). I'll do a deep dive into their docco and see
what they actually do! I'm actually very interested in the
benchmarking side of database technology - but I do know the old adage
- there are lies, damned lies, statistics and *_then_* there are
database benchmarks (as seen with the link I posted!).

Thanks for your input.

Best regards,


El!

> merlin