3 ms·

If I had a penny for every HA postgres solution

by navls 11y ago

Rafert 11y ago
I'm no Postgres expert, why isn't something like this built in to the product itself?
- dijit 11y ago
  the developers "do one thing and do it well" it's better to have a flexible 'correct' implementation of a DB instead of baking in features which make it more complex and less extensible.
- creshal 11y ago
  Postgres' motto is "do it right, or don't do it at all". The developers rather let other projects (or postgres addons) figure out the all the hidden traps and then implement a better-than-average solution on the first try a few years later. Cf. their JSON support, which regularly outperforms dedicated NoSQL databases; they're also slowly integrating building blocks for multi-master replication, while still holding out on actually implementing it – seeing MariaDB's recent track record with their solution ( https://aphyr.com/posts/328-call-me-maybe-percona-xtradb-cluster https://aphyr.com/posts/328-call-me-maybe-percona-xtradb-clu... ), probably a good decision.
- saurik 11y ago
  PostgreSQL only adds clean, well thought-out, maintainable, and fully reliable implementations of features to their codebase. In stark contrast to many other open source database products, when PostgreSQL adds something, barring often one or two bugs found in the .0 release, you can trust it works now and will continue working pretty much forever. I appreciate this approach, and it is why I have been using PostgreSQL now for almost fifteen years. This particular feature is something that is difficult to make correct (see Jepson complaining about essentially everyone) as well as difficult to come up with a model that supports more than a few narrow use cases. If you need something now it is better than people are being directed to third-party products that can be built on the solid core of PostgreSQL, and which then will have clear expectations associated with them.
  - lobster_johnson 11y ago
    The result of this strategy is an extraordinary lack of cruft. Postgres has some obscure unpopular features, but it really doesn't have any legacy behaviour. If you read the MySQL documentation, it's full of "until version 5.7.7.3 this returned NULL if..." or "this will accept invalid dates unless a certain mode flag is enabled" (I'm paraphrasing, obviously). Postgres has none of this. They do occasionally deprecate features, such as OIDs, which are supported but not recommended (or particularly useful), or they change some key behaviour (standard_conforming_strings). Sometimes the development strategy leads to incomplete or overlapping functionality because they prefer discrete, additive changes over big, one-off overhauls. But in general, Postgres' conservative strategy has really paid off.
- Jweb_Guru 11y ago
  To discourage people from using something broken. You're talking about a database that waited until 2011 to add a SERIALIZABLE implementation because the existing solutions all sucked, and only did it then because of new research (SSI). They have zero qualms about keeping features out of the database, no matter how useful, if they can't be implemented well.
  - aravindet 11y ago
    > They have zero qualms about keeping features out of the database, no matter how useful, if they can't be implemented well. Another example, INSERT ... ON CONFLICT UPDATE (UPSERT/MERGE) available just now in the 9.5 beta.
  - notpeter 11y ago
    Forget serializable, PostgreSQL 7.0 included functional ACID-safe transactions 5 years before MySQL but didn't include LEFT OUTER JOIN (http://www.postgresql.org/docs/7.1/static/release-7-1.html http://www.postgresql.org/docs/7.1/static/release-7-1.html) . That was my first taste of "if you can't do it right, don't ship it."

If I had a penny for every HA postgres solution

by navls 11y ago

If I had a penny for every HA postgres solution

Rafert 11y ago

I'm no Postgres expert, why isn't something like this built in to the product itself?

dijit 11y ago
the developers "do one thing and do it well" it's better to have a flexible 'correct' implementation of a DB instead of baking in features which make it more complex and less extensible.
creshal 11y ago
Postgres' motto is "do it right, or don't do it at all". The developers rather let other projects (or postgres addons) figure out the all the hidden traps and then implement a better-than-average solution on the first try a few years later. Cf. their JSON support, which regularly outperforms dedicated NoSQL databases; they're also slowly integrating building blocks for multi-master replication, while still holding out on actually implementing it – seeing MariaDB's recent track record with their solution ( https://aphyr.com/posts/328-call-me-maybe-percona-xtradb-cluster https://aphyr.com/posts/328-call-me-maybe-percona-xtradb-clu... ), probably a good decision.
saurik 11y ago
PostgreSQL only adds clean, well thought-out, maintainable, and fully reliable implementations of features to their codebase. In stark contrast to many other open source database products, when PostgreSQL adds something, barring often one or two bugs found in the .0 release, you can trust it works now and will continue working pretty much forever. I appreciate this approach, and it is why I have been using PostgreSQL now for almost fifteen years. This particular feature is something that is difficult to make correct (see Jepson complaining about essentially everyone) as well as difficult to come up with a model that supports more than a few narrow use cases. If you need something now it is better than people are being directed to third-party products that can be built on the solid core of PostgreSQL, and which then will have clear expectations associated with them.
- lobster_johnson 11y ago
  The result of this strategy is an extraordinary lack of cruft. Postgres has some obscure unpopular features, but it really doesn't have any legacy behaviour. If you read the MySQL documentation, it's full of "until version 5.7.7.3 this returned NULL if..." or "this will accept invalid dates unless a certain mode flag is enabled" (I'm paraphrasing, obviously). Postgres has none of this. They do occasionally deprecate features, such as OIDs, which are supported but not recommended (or particularly useful), or they change some key behaviour (standard_conforming_strings). Sometimes the development strategy leads to incomplete or overlapping functionality because they prefer discrete, additive changes over big, one-off overhauls. But in general, Postgres' conservative strategy has really paid off.
Jweb_Guru 11y ago
To discourage people from using something broken. You're talking about a database that waited until 2011 to add a SERIALIZABLE implementation because the existing solutions all sucked, and only did it then because of new research (SSI). They have zero qualms about keeping features out of the database, no matter how useful, if they can't be implemented well.
- aravindet 11y ago
  > They have zero qualms about keeping features out of the database, no matter how useful, if they can't be implemented well. Another example, INSERT ... ON CONFLICT UPDATE (UPSERT/MERGE) available just now in the 9.5 beta.
- notpeter 11y ago
  Forget serializable, PostgreSQL 7.0 included functional ACID-safe transactions 5 years before MySQL but didn't include LEFT OUTER JOIN (http://www.postgresql.org/docs/7.1/static/release-7-1.html http://www.postgresql.org/docs/7.1/static/release-7-1.html) . That was my first taste of "if you can't do it right, don't ship it."