On Thu, Jul 28, 2016 at 8:16 AM, pgwhatever <mich...@sqlexec.com> wrote: > Statement-Based replication has a lot of problems with it like indeterminate > UDFs. Here is a link to see them all: > https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html#replication-sbr-rbr-sbr-disadvantages
Sure. It's also incredibly efficient with respect to bandwidth -- so, if you're application was engineered to work around those problems it's a huge win. They could have used pgpool, but I guess the fix was already in. Taking a step back, from the outside, it looks like uber: *) has a very thick middleware, very thin database with respect to logic and complexity *) has a very high priority on quick and cheap (in terms of bandwidth) replication *) has decided the database needs to be interchangeable *) is not afraid to make weak or erroneous technical justifications as a basis of stack selection (the futex vs ipc argument I felt was particularly awful -- it ignored the fact we use spinlocks) The very fact that they swapped it out so easily suggests that they were not utilizing the database as they could have, and a different technical team might have come to a different result. Postgres is a very general system and rewards deep knowledge such that it can outperform even specialty systems in the hands of a capable developer (for example, myself). I'm just now hammering in the final coffin nails that will get solr swapped out for jsonb backed postgres. I guess it's fair to say that they felt mysql is closer to what they felt a database should do out of the box. That's disappointing, but life moves on. The takeaways are: *) people like different choices of replication mechanics -- statement level sucks a lot of the time, but not all the time *) hs/sr simplicity of configuration and operation is a big issue. it's continually gotten better and still needs to *) bad QC can cost you customers. how much regression coverage do we have of hs/sr? *) postgres may not be the ideal choice for those who want a thin and simple database merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
