Index bloat reduced in PostgreSQL v14
cybertec-postgresql.com
Index bloat reduced in PostgreSQL v14
1–10 of 93 posts
Re: Index bloat reduced in PostgreSQL v14
#2I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
Re: Index bloat reduced in PostgreSQL v14
#3I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
Shit the bed worse than Oracle? Not in my experience, unless it's from abuse (storing 1000x 128mb blob per single row, making 100000 simultaneous connections+transactions on a 1-cpu instance, etc).
Most of this seems to originate from people treating PG as "magic", which it is....... until it isn't
Re: Index bloat reduced in PostgreSQL v14
#4I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
Replication is often talked about as being more difficult than in MySQL.
Re: Index bloat reduced in PostgreSQL v14
#5I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
Until recent versions CTEs could be very inefficient where they would not be in other databases, though that has now been addressed unless you are running an older release. I'm can't think of any major data loss stories, though there have been one or two "why we switched from pg to " ones.
Re: Index bloat reduced in PostgreSQL v14
#6I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
Replication is often talked about as being more difficult than in MySQL.
Especially since Galera entered the picture:
* https://packages.debian.org/search?keywords=galera
There's BDR, but it's a commercial product from 2ndQuadrant/EDB:
* https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndqua...
Re: Index bloat reduced in PostgreSQL v14
#7I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
I love postgres, but foreign data wrappers are not really good for much production use in my experience. The query planners need more work, as sometimes they do inconsistent things. The biggest issues is not taking advantage of indices sometimes. Hoping it's solid by version 15 or so.
Re: Index bloat reduced in PostgreSQL v14
#8Congratulations to the PostgreSQL community! You guys do an amazing work! Thanks
Re: Index bloat reduced in PostgreSQL v14
#9I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
It's not a limitation that affects most of users, but lack of official multi master support makes it less suitable for "always on" databases. But to be honest multi master is something hard to get right in ANY database. PostgreSQL is great for many use cases and good enough for many more!
Re: Index bloat reduced in PostgreSQL v14
#10I'm sure we'll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)
I don't remember specifics, but that Uber article made it clear that they didn't understand how Postgres worked and made some very basic mistakes. The whole thing made them seem surprisingly incompetent, although the general crappiness of Uber apps maybe should have tipped me off sooner.