3 ms·
1) 2003 was 17 years ago. 2) PG has a write amplification problem with multiple indexes that MySQL Innodb doesn't have.
by redis_mlc 7y ago
1) 2003 was 17 years ago.
2) PG has a write amplification problem with multiple indexes that MySQL Innodb doesn't have.
- asah 7y agoI'm curious how innodb solves this, given that the theory of indices pretty much demands write amplification by definition. Postgres' WA is worse?
- edoceo 7y agoIts from an Uber post - more story and follow up in this post https://dba.stackexchange.com/questions/226879/did-postgresql-write-amplification-reduction-warm-efforts-get-released-in-10-1 https://dba.stackexchange.com/questions/226879/did-postgresq...
- djd20 7y agoYeah - they indexed every single column.... also - what may not have worked for uber, will be just fine for 99% of usecases. How often do you work with that kind of load. What they moved to isn't so much mysql, rather mysql used as a key value store with 0 relational database usage. Not really a postgres issue, rather one of being too big for relational databases.
- edoceo 7y ago2003 was when I picked PG as preferred. Since then I've continues to work with DBs and of course evaluated Maria at least every 18 months (or a client was paying me to do this). PG continues to win for nearly every case I throw at it. Like when NoSQL was a fad (why tho!?) but PG had native json, then jsonb types. I didn't even have to look at that silly Mongo, PG baba!
- djd20 7y agoYou have a problem if you're trying to index every column...