Re: Why we lost Uber as a user

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alfred Perlstein <alfred(at)freebsd(dot)org>
Cc: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why we lost Uber as a user
Date: 2016-08-02 19:46:48
Message-ID: CA+Tgmobptqs4ze6uvrVS-KeTMVJNObkuzukCuak6n+H5Dr9cew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 2, 2016 at 3:07 PM, Alfred Perlstein <alfred(at)freebsd(dot)org> wrote:
> You are quite technical, my feeling is that you will understand it, however it will need to be a self learned lesson.

I don't know what this is supposed to mean, but I think that Geoff's
point is somewhat valid. No matter how you replicate data, there is
always the possibility that you will replicate any corruption along
with the data - or that your copy will be unfaithful to the original.
The possible advantage of logical replication rather than physical
replication is that any errors you replicate will be logical errors
rather than physical errors - so if the heap gets out of step with the
indexes on the master, the same problem will not necessarily occur on
the slave. On the flip side, despite what Uber found in their
environment, physical replication tends to be high-performance because
the replay is dead simple. Andres and others have done a good job
making our logical decoding facility fast, but I believe it's still
slower than plain old physical replication and probably always will
be, and the trigger-based logical replication solutions are slower
still. Consequently, I believe that both physical and logical
replication have advantages, and that's why we should support both of
them. Then, each individual user can make the trade-offs they prefer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-08-02 19:51:06 Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Previous Message Chapman Flack 2016-08-02 19:43:45 Re: AdvanceXLInsertBuffer vs. WAL segment compressibility