4 ms·

What are the “plenty of examples of things MySQL can do that Postgres can’t”? I honestly can’t think of one, much less “plenty”.

gymbeaux 3y ago
Yeah I can’t think of any. I mean if I had to come up with something, I would talk about tooling. MySQL Workbench (when it works) is by far the easiest to use and most feature-rich of all RDBMS.. MS. It runs on any OS too, which is a ding on SQL Server and not Postgres since Postgres’ is a web app- which has the limitations of a web app (no right click for example- which I know is possible in a web app, but last I checked not implemented for pgadmin).
evanelias 3y ago
These are just a few random ones off the top of my head! * Handling several thousand connections per second without needing a proxy or pool (MySQL's connection model is thread/conn vs Postgres using process/conn) * Handle extremely high volume of primary key range scan queries (MySQL's InnoDB uses a clustered index, see https://news.ycombinator.com/item?id=35909053 https://news.ycombinator.com/item?id=35909053) * Handle workloads that lean heavily on UPDATE or DELETE, without major MVCC pain (see https://ottertune.com/blog/the-part-of-postgresql-we-hate-the-most https://ottertune.com/blog/the-part-of-postgresql-we-hate-th... for example) * Semi-synchronous logical replication, for environments which cannot tolerate any data loss during failover; this ensures the statements have reached at least one replica but without the huge latency of synchronous replication * Use index hints, to ensure random index stats changes don't cause unexpectedly negative query plan adjustments (see discussion in subthread https://news.ycombinator.com/item?id=35909340 https://news.ycombinator.com/item?id=35909340) * Handle very high-volume OLTP workloads using direct I/O, since InnoDB's buffer pool design is completely independent of filesystem/OS caching * Achieve best-in-industry compression by using the MyRocks storage engine (MySQL's pluggable storage engine design has a lot of tradeoffs but it is inherently what makes this even possible) * Use UNSIGNED int types, to store twice as high max value in the same number of bytes, if you know negative numbers are not going to be present * Use case-insensitive or accent-insensitive collations out-of-the-box without having to monkey with confusing user-defined CREATE COLLATION * Ease-of-use commands like SHOW CREATE TABLE * Silly cosmetic things like the ability to reorder columns in an ALTER TABLE (see https://wiki.postgresql.org/wiki/Alter_column_position https://wiki.postgresql.org/wiki/Alter_column_position) * A tooling ecosystem which includes multiple battle-tested external online schema change tools, for safely making alterations of any type to tables with billions of rows
- bigblackrooster 3y ago
  ratio

gymbeaux 3y ago

Yeah I can’t think of any. I mean if I had to come up with something, I would talk about tooling. MySQL Workbench (when it works) is by far the easiest to use and most feature-rich of all RDBMS.. MS. It runs on any OS too, which is a ding on SQL Server and not Postgres since Postgres’ is a web app- which has the limitations of a web app (no right click for example- which I know is possible in a web app, but last I checked not implemented for pgadmin).

evanelias 3y ago

These are just a few random ones off the top of my head! * Handling several thousand connections per second without needing a proxy or pool (MySQL's connection model is thread/conn vs Postgres using process/conn) * Handle extremely high volume of primary key range scan queries (MySQL's InnoDB uses a clustered index, see https://news.ycombinator.com/item?id=35909053 https://news.ycombinator.com/item?id=35909053) * Handle workloads that lean heavily on UPDATE or DELETE, without major MVCC pain (see https://ottertune.com/blog/the-part-of-postgresql-we-hate-the-most https://ottertune.com/blog/the-part-of-postgresql-we-hate-th... for example) * Semi-synchronous logical replication, for environments which cannot tolerate any data loss during failover; this ensures the statements have reached at least one replica but without the huge latency of synchronous replication * Use index hints, to ensure random index stats changes don't cause unexpectedly negative query plan adjustments (see discussion in subthread https://news.ycombinator.com/item?id=35909340 https://news.ycombinator.com/item?id=35909340) * Handle very high-volume OLTP workloads using direct I/O, since InnoDB's buffer pool design is completely independent of filesystem/OS caching * Achieve best-in-industry compression by using the MyRocks storage engine (MySQL's pluggable storage engine design has a lot of tradeoffs but it is inherently what makes this even possible) * Use UNSIGNED int types, to store twice as high max value in the same number of bytes, if you know negative numbers are not going to be present * Use case-insensitive or accent-insensitive collations out-of-the-box without having to monkey with confusing user-defined CREATE COLLATION * Ease-of-use commands like SHOW CREATE TABLE * Silly cosmetic things like the ability to reorder columns in an ALTER TABLE (see https://wiki.postgresql.org/wiki/Alter_column_position https://wiki.postgresql.org/wiki/Alter_column_position) * A tooling ecosystem which includes multiple battle-tested external online schema change tools, for safely making alterations of any type to tables with billions of rows

bigblackrooster 3y ago
ratio