Hacker News Reader

Comment by smcleod | Hacker News Reader

I'd agree except that PostgreSQL performance seems to have always won over MySQL in non-synthetic tests regardless, perhaps just through good quality engineering they haven't needed to 'worry' about performance until later.

View on HN

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.

They are working to fix that. It didn't make it into PG10 but the developers are aiming for PG11.

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.

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.

> when MySQL didn't have transactions, it was the fastest "database" for writes!

`/dev/null` is the fastest "database" for writes ;)

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.

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-postg...

Where do you draw the line on synthetic vs. non-synthetic tests, and do you know where I should look to find them?

Reply on news.ycombinator.com