Live data from Hacker News

An early look at Postgres 14: Performance and monitoring Improvements

pganalyze.com

121–130 of 254 posts

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

#121

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…

There's a ton of room for improvement in the architecture of relational databases. This isn't a dig against Postgres, or ignoring how difficult it will be to get a new system to the same level of maturity. But databases designed natively for cloud/clustering, SSDs, (pmem soon perhaps), etc are quite a bit different. There's enormous simplifications and performance gains possible. There's been a lot of exciting work i…

You must be kidding me with the CosmosDB mention. It doesn't even have foreign key constraints. I have to work with it and I have never seen such a feature-poor dbms before.

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

#122

All I want is to be able to use Postgres in production without the need of pgbouncer.

Never had the use for it or even heard of it, guess it depends on usage patterns? I've mostly worked with longlived java servers, and there having an internal db pool has been standard since forever, so no need for another layer.

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

#123
post #99

Earlier quoted context omitted.

Not much different from some_jsonb#>>'{some,path}' and once you add the need to convert out of jsonb to text, you'll not be saving any characters either. At least for queries. For updates, it looks nice I guess.

I think the difference is familiarity . It shouldn't matter so much, but when you don't use one language as much as you do other languages, it becomes that much harder to remember unfamiliar syntaxes and grammars, and easier to confuse similar looking operations with each other.

In that case this does not help. SELECT json['a']; will not return the value of the string in {"a":"ble"} (like it does in Javascript), but a JSON encoding of that string, so '"ble"'. You'll still not be able to do simple comparisons like `SELECT json_col['a'] = some_text_col;` Superficial familiarity, but it still behaves differently than you expect.

Is there even a function that would convert JSON encoded "string" to text it represents in postgresql? I didn't find it.

So all you can do is `SELECT json_col['a'] = some_text_col::jsonb;` and hope for the best (that string encodings will match) or use the old syntax with ->> or #>>.

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

#124

Earlier quoted context omitted.

I mean... the WORST? For me Mongo takes the cake, but oracle is up there too.

Really? Oracle actually makes a lot of sense to me for a database name (in the 'source of truth' sense, not in the prophet sense). Mongo, on the other hand, has definitely always had the racist/ablist slur as the first connotation for me.

I've learned almost all the slurs I know from comments or media sources complaining about them. It's the only place they're used in polite society.

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

#125
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

Not totally ideal if you're using containers as it requires the binaries of the old and new version, unless I'm missing something.

All distros I've ever used (debian, arch) provide previous and current version of postgresql for the purpose of easy pg_upgrade.

Debian even has special custom helper scripts for doing it. So just build your container with both postgres versions?

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

#126
post #41

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…

> Do any other entrenched software projects come to mind? SQLite.

I'm pretty hopeful that DuckDB will replace some of the use of SQLite. SQLite is great but it sucks that it's entirely dynamically typed (the types specified for columns are completely ignored).

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

#127
post #112

Earlier quoted context omitted.

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 loa…

Out of curiosity, do you know what causes this?

They mention this in the article. But to sum up, each connection in PG is handled by its own OS process. Postgres behind the scenes is composed by multiple single-threaded applications.

This comes with the advantes for Pg developers (and us!) that they don't need to deal with tons of data races issues, but the trade off is that memory wise, a process takes way more memory than a thread.

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

#128
post #99
post #88

Earlier quoted context omitted.

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

Not much different from some_jsonb#>>'{some,path}' and once you add the need to convert out of jsonb to text, you'll not be saving any characters either. At least for queries. For updates, it looks nice I guess.

Downvoters could instead provide a way to get a decoded text of a property with this new syntax, like it's possible with #>>. That would be more useful.

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

#129
post #95
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/

Gods, but this is fabulous! JSONB capabilities in Postgres are amazing, but the syntax is really annoying - for example, I'm forever mixing up `->` and `->>`. This new syntax feels far more intuitive.

Constantly have to google up the JSONB wuery syntax, it's just too confusing to me, although it is indeed powerful.

Glad to this this super intuitive and familiar syntax added. Will make writing these updates a lot lot lot easier. Not even close!

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

#130
post #75

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…

> Do any other entrenched software projects come to mind? Elasticsearch is underrated here, IMO. Yes, there are alternatives for simple fulltext search. But there’s a lot more it can do (adhoc aggregations incorporating complex fulltext searches, with custom scripted components; geospatial; index lifecycle management) and if you’re using those features, there’s nothing else comparable. It’s pretty stable, too, once y…

It’s frustrating to need a run-time team for a piece of infrastructure, especially one sold as IaaS.

It’s totally understandable that you’d need developers to have expertise in patterns and anti-patterns, as well as needing an expert to set things up in the first place, but you shouldn’t have to have a dedicated ES monitoring / tuning / babysitting team like Oracle DBAs of yore. That you do, means it isn’t there yet as a product.

Post reply on HN