Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An early look at Postgres 14: Performance and monitoring Improvements

pganalyze.com

Post reply on HN
Print view View original

81–90 of 254 posts

Re: An early look at Postgres 14: Performance and monitoring Improvements

#81

Post by darkwater »

jeffbee wrote: post #32
andruby wrote: post #26

Earlier quoted context omitted.

Pg_upgrade [0] is an official part of postgres and does the binary inplace upgrade for you. You should obviously test before running in production, but it has worked perfectly for us when upgrading a 10+TB cluster from pg11 to pg13 [0] https://www.postgresql.org/docs/current/pgupgrade.html

10TB is basically zero. At that scale you can choose anything and get away with it.

How can someone with 10k karma write such a statement? Were you trolling? Are you serious? 10TB of relational database can be definetly troublesome to manage and pose challenges to many organizations.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#82

Post by stickfigure »

matthewbauer wrote: post #5

Postgres is one of those pieces of software that’s so much better than anything else, it’s really incredible. I wonder if it’s even possible for competitors to catch up at this point - there’s not a lot of room for improvement in architecture of relational databases any more. I’m starting to think that Postgres is going to be with us for decades maybe even centuries. Do any other entrenched software projects come to…

I'm an enormous fan of Postgres, it's my default go-to RDBMS. But the memory expense of connections is a huge issue and this article doesn't convince me that it's solved.

The machine being used for this benchmark has 96 vCPUs, 192G of RAM, and costs $3k/mo.

My business runs just fine on a 3.75G, 1 vCPU instance. But idle connections eat up a huge amount of RAM and I sometimes find myself hitting the limits when a load spike spins up extra frontend instances.

Sure I could probably setup pgbouncer and some other tools but that's a lot of headache. I'm acutely aware that MySQL (which I dislike because no transactional DDL) does not suffer from this issue. I also don't see this being solved without a major rewrite, which seems unlikely.

So Postgres has at least one very serious fault that makes room in the marketplace. The poor replication story is another.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#83

Post by sigzero »

wiradikusuma wrote: post #3

I'm thinking of using Postgres for a project, but a DBA friend told me operationally it's more challenging than MySQL. Unfortunately, he can't elaborate. Does anyone have real work experience? Or is it based on outdated "PG must manually vacuum frequently"?

MySQL is for that aren't really DBAs and don't want to be (this doesn't mean DBAs don't use it). It's a lot easier to manage.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#84

Post by znep »

efxhoy wrote: post #39

> Automatic cancellation of long-running queries if the client disconnects Sweet! I often screw up a query and need to cancel it with pg_cancel_backend(pid) because Ctrl-C rarely works. With this I can just ragequit and reconnect. Sweet!

I agree this is a great addition, but FWIW it isn't normal for ^C to not work in psql. Perhaps you are using some other client that doesn't support aborting queries properly, or have something on the network between you and the server behaving poorly and dropping connections?

Re: An early look at Postgres 14: Performance and monitoring Improvements

#85

Post by bredren »

Waterluvian wrote: post #15

Tangential to this topic: If I have a Django + PG query that takes 1 second and I want to deeply inspect the breakdown of that entire second, where might I begin reading to learn what tools to use and how?

Just in case someone’s reading this and isn’t also aware: Django Debug Toolbar offers somewhat interactive exploration of queries.

It can also be used with Django Rest Framework via the browsable api.

May be parent is looking for deeper insight than this but it is useful to do quick visual query inspection.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#86

Post by bredren »

If you’re interested in recent enthusiastic (nearly effusive) discussion of Postgres and more specifically it’s potential as a basis for a data warehouse, you might enjoy this episode of Data Engineering Podcast with Thomas Richter and Joshua Drake:

Episode website: https://www.dataengineeringpodcast.com/postgresql-data-wareh...

Direct: (apple) https://podcasts.apple.com/us/podcast/data-engineering-podca...

Re: An early look at Postgres 14: Performance and monitoring Improvements

#87

Post by jeff-davis »

matthewbauer wrote: post #5

Postgres is one of those pieces of software that’s so much better than anything else, it’s really incredible. I wonder if it’s even possible for competitors to catch up at this point - there’s not a lot of room for improvement in architecture of relational databases any more. I’m starting to think that Postgres is going to be with us for decades maybe even centuries. Do any other entrenched software projects come to…

I like to say that "Postgres is a great default". It's generally very good, and also very adaptable to special purposes, so it covers a wide range of use cases.

But saying "so much better" is too strong.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#88

Post by xfalcox »

e1g wrote: post #80

Another exciting feature in PG14 is the new JSONB syntax[0], which makes it easy to update deep JSON values - UPDATE table SET some_jsonb_column['person']['bio']['age'] = '99'; [0] https://erthalion.info/2021/03/03/subscripting/

Wow is this for real? That is such a big quality of life change! Happy to see it!

Re: An early look at Postgres 14: Performance and monitoring Improvements

#89

Post by eikenberry »

Any progress on high availability deployments yet? Or does it still rely on problematic, 3rd party tools?

Last time I was responsible for setting up a HA Postgres cluster it was a garbage fire, but that was nearly 10 years ago now. I ask every so often to see if it has improved and each time, so far, the answer has been no.

Re: An early look at Postgres 14: Performance and monitoring Improvements

#90

Post by rusbus »

eikenberry wrote: post #89

Any progress on high availability deployments yet? Or does it still rely on problematic, 3rd party tools? Last time I was responsible for setting up a HA Postgres cluster it was a garbage fire, but that was nearly 10 years ago now. I ask every so often to see if it has improved and each time, so far, the answer has been no.

I found running a 6-node Patroni cluster on Kubernetes to be a surprisingly pain-free experience a couple of years ago
Post reply on HN