Live data from Hacker News

Index bloat reduced in PostgreSQL v14

cybertec-postgresql.com

11–20 of 93 posts

Re: Index bloat reduced in PostgreSQL v14

#11
post #2

I'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)

Well I wish I could embed it as sqlite, but that is like me dreaming too big!

Re: Index bloat reduced in PostgreSQL v14

#12
post #9
post #2

I'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!

Lately I've been getting a lot of notifications for BDR (short for Bi-Directional Replication) from EDB; the term 'Always On' also appears in those notifications, apparently to woo the Oracle audiences. You might want to take a look into that.

Disclosures/info: I used to work for EDB. BDR was developed by 2nd Quadrant, which was recently acquired by EDB.

Re: Index bloat reduced in PostgreSQL v14

#13
post #10
post #2

I'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.

In what way did they make basic mistakes?

Re: Index bloat reduced in PostgreSQL v14

#14
post #9
post #2

I'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!

Why would you need multi master to be "always on"?

Re: Index bloat reduced in PostgreSQL v14

#17
post #9
post #2

I'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!

The basic HA support is there, and is very well described in the docs. What Postgres doesn't provide is the mechanism to pick when to automatically promote a replica to primary, but that's because this is a system-level concern that's entirely outside the database featureset itself.

Re: Index bloat reduced in PostgreSQL v14

#18
post #10
post #2

I'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.

Fwiw I personally find their android apps to be among the highest quality of any android app I encounter.

Re: Index bloat reduced in PostgreSQL v14

#19
post #10
post #2

I'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.

Speaking about mistakes, do you have any good resources on Postgres to ensure that you don't make the same kind of mistakes?

Re: Index bloat reduced in PostgreSQL v14

#20
post #19
post #10

Earlier quoted context omitted.

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.

Speaking about mistakes, do you have any good resources on Postgres to ensure that you don't make the same kind of mistakes?

Hear hear!

I am really loving Postgres after a foray with Oracle. But I get concerned about using it for large production loads. I welcome recommendations as well.

Post reply on HN