Re: A not so good comparison of MVCC implementations

From: Jonathan S. Katz
Subject: Re: A not so good comparison of MVCC implementations
Date: ,
Msg-id: 8D45F97E-ACDA-4B2A-8793-53CA954EBA4F@postgresql.org
(view: Whole thread, Raw)
In response to: Re: A not so good comparison of MVCC implementations  (Robert Haas)
Responses: Re: A not so good comparison of MVCC implementations  (Robert Haas)
List: pgsql-advocacy

Tree view

A not so good comparison of MVCC implementations  (Thomas Kellerer, )
 Re: A not so good comparison of MVCC implementations  (Stephen Frost, )
  Re: A not so good comparison of MVCC implementations  (Robert Haas, )
   Re: A not so good comparison of MVCC implementations  (Christophe Pettus, )
   Re: A not so good comparison of MVCC implementations  ("Jonathan S. Katz", )
    Re: A not so good comparison of MVCC implementations  (Robert Haas, )
     Re: A not so good comparison of MVCC implementations  ("Jonathan S. Katz", )
      Re: A not so good comparison of MVCC implementations  (Michael Paquier, )

Hi,

> On Jan 26, 2018, at 1:08 PM, Robert Haas <> wrote:
>
> On Fri, Jan 26, 2018 at 7:22 AM, Stephen Frost <> wrote:
>> * Thomas Kellerer () wrote:
>>> https://dzone.com/articles/database-design-decisions-for-multi-version-concur
>>>
>>> That doesn't make Postgres look particular well
>>
>> While interesting, if I'm following the paper correctly, they didn't
>> actually test *Postgres*, they tested their own implementation of how PG
>> works using "Peloton".
>
> Yeah, that's really deceptive.

Skimming the paper, it also does not mention which versions of the software
are being used.  Ideally how the DBs were configured on the hardware
would be great to see too, but that may be asking too much.


>> They also, apparently, discounted latency pretty
>> heavily given that their graph shows their "PG" implementation having
>> the lowest latency of all of the options.
>
> Also, they seem to be comparing against PostgreSQL with SSI running
> (transaction isolation level serializable) which is not actually the
> way that people typically configure PostgreSQL.
>
> The point of the article seems to be to say that NuoDB made some good
> design decisions, rather than to objective compare existing systems.

So the question is if and how we respond.  From a scan of the Twittersphere
I do not see much talk about the paper, so I would not give it that much
thought at this point and would not advocate for proactively addressing it.

However, if anyone wants to independently benchmark it and provide some fair
comparisons, that is something that we’ve certainly promoted through Planet
PostgreSQL.

Additionally, if anyone wants to comment to others who are referencing that paper
e.g. on Twitter etc. there are enough sound points in this thread alone to help
make the case of Postgres even without additional data.

> Unsurprisingly,
> there are lots of trade-offs to be made and we continue to look at
> ways to make PostgreSQL more flexible to allow users to choose which
> trade-offs work best for their workload.

+1

Jonathan


pgsql-advocacy by date:

From: Robert Haas
Date:
Subject: Re: A not so good comparison of MVCC implementations
From: "Jonathan S. Katz"
Date:
Subject: Re: A not so good comparison of MVCC implementations