4 ms·
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, keepi
by 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 agoThey are working to fix that. It didn't make it into PG10 but the developers are aiming for PG11.
- dorfsmay 10y agoI 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 agoIf 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 ;)