4 ms·

I don't know the answer in this case, but a few thoughts: * Why don't you think the optimizer is a consideration? That's a big deal, because it helps the datab

I don't know the answer in this case, but a few thoughts: * Why don't you think the optimizer is a consideration? That's a big deal, because it helps the database choose the right algorithms as your data changes. Continuing gracefully while the input data is changing sounds like scalability to me. * Postgres is generally considered to scale to many concurrent connections and many cores. Useful for OLTP. * Sometimes the right feature or extensibility hook can make a huge difference allowing you to do the work in the right place at the right time. For instance, LISTEN/NOTIFY makes it easier to build a caching layer that's properly invalidated -- not trivial to get right if the feature is missing, which might mean that you're not getting as much out of caching as you could be. Tuning for SSDs, compression, buffer caching, etc., are the antithesis of scalability. Those things are pure performance issues. Scalability is about a system that adapts as input data and processing resources change. (Your point about replication does concern scalability, of course.)

vidarh 13y ago
> * Postgres is generally considered to scale to many concurrent connections and many cores. Useful for OLTP. But MySQL scales trivially to many servers. Postgres replication is finally getting there, but it's been incredibly slow coming, while setting up huge MySQL installations with a dozen+ replicas, with selective sharding etc. has been effortless for about a decade.
- damncabbage 13y ago
  ... while setting up huge MySQL installations with a dozen+ replicas ... If you're careful about your function calls, sure. Include a UUID() or SYSDATE() in your INSERT statements, and the replication goes to pieces as the function calls are run separately on each slave (with differing results).
  - morgo 13y ago
    I recommend switching to Row-based Replication, which avoids this problem.

vidarh 13y ago

> * Postgres is generally considered to scale to many concurrent connections and many cores. Useful for OLTP. But MySQL scales trivially to many servers. Postgres replication is finally getting there, but it's been incredibly slow coming, while setting up huge MySQL installations with a dozen+ replicas, with selective sharding etc. has been effortless for about a decade.

damncabbage 13y ago
... while setting up huge MySQL installations with a dozen+ replicas ... If you're careful about your function calls, sure. Include a UUID() or SYSDATE() in your INSERT statements, and the replication goes to pieces as the function calls are run separately on each slave (with differing results).
- morgo 13y ago
  I recommend switching to Row-based Replication, which avoids this problem.