4 ms·

I'd agree except that PostgreSQL performance seems to have always won over MySQL in non-synthetic tests regardless, perhaps just through good quality engineerin

• JimDabell 10y ago
  That wasn't always the case, but it's easier to start with something correct and make it fast than it is to start with something fast and make it correct.
• hyperpape 10y ago
  Where do you draw the line on synthetic vs. non-synthetic tests, and do you know where I should look to find them?
• dorfsmay 10y ago
  No, when MySQL didn't have transactions, it was the fastest "database" for writes! Also, as somebody who's being very careful with which fields I update, keeping in mind indexes, I'm still in shock about learning that PostgreSQL updates all indexes on a table, even for columns not included in that write - that ha to have a cost.
  • rpedela 10y ago
    They are working to fix that. It didn't make it into PG10 but the developers are aiming for PG11.
    • dorfsmay 10y ago
      I know, it just was so unexpected. Very few people realised that this is how it worked until some big blog post a few months ago.
  • chanks 10y ago
    If you have a table that undergoes frequent updates and this is a concern of yours, look into setting a fillfactor on it. This will help Postgres keep writes in the same page, which means it doesn't need to touch indexes for non-indexed columns. Edit: non-updated columns, I mean.
  • 6t6t6t6 10y ago
    > when MySQL didn't have transactions, it was the fastest "database" for writes! `/dev/null` is the fastest "database" for writes ;)
• olegkikin 10y ago
  You can always find (pretty basic) examples where either one is faster, and sometimes by a lot. http://dba.stackexchange.com/questions/149729/mysql-vs-postgresql-benchmarking-count-execution-speed http://dba.stackexchange.com/questions/149729/mysql-vs-postg...