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

241–250 of 254 posts

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

#241

Post by randomswede »

golergka wrote: post #220
salmo wrote: post #156

Earlier quoted context omitted.

Containerized DBs are great for dev work, toy projects, etc. Notsomuch for production. I know... folks do it. But I wouldn't run anything on it that I wouldn't do w/ sqlite.

Why not? Having the whole application in one Kubernetes setup, with all databases and other services is very convenient. Are you talking about performance overhead, or are there other drawbacks to this approach?

The main problem is "persistent storage". In k8s, a PVC/PV is probably close to the right answer, but in general that gives you a file-system view of the storage, not a block-device view, which for some databases might matter).

Also, in general, that persistent storage is (generally) not locally attached, which means that (some) file system interactions may have unexpected semantics. Now, with a DB, you're probably only going to have the PV attached on a single worker node, so most of that will actually just work.

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

#242

Post by ChrisRackauckas »

TheRealKing wrote: post #235
nsajko wrote: post #225

Earlier quoted context omitted.

> Fortran for linear algebra software. Not an expert, but it is my understanding that Julia is becoming an ever more serious competitor day by day. > Excel for business spreadsheets. Honest question, what does LibreOffice miss compared to Excel? In any case, (again not an expert) spreadsheets seem quite inferior to a combination of Julia, CSV and Vega (Lite); although there are certainly more people that are familiar…

Julia has a long way to get there, where Fortran is in terms of stability and maturity, needs approximately 60 years more.

What issue do you have with the use of RecursiveFactorization.jl in DifferentialEquations.jl? I can't think of a maturity issue so I'm curious what you have found, or whether this comment isn't grounded in specifics.

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

#243

Post by marco_craveiro »

macdice wrote: post #142
threeseed wrote: post #100

Earlier quoted context omitted.

There are also technologies like NVMe over Fabric/RDMA, eBPF, XDP, io_uring etc which are just starting to get traction and are game changers for performance. None of which are being used. All of these require a different architecture so expect to see newer databases push things even further.

Peope are working on io_uring for PostgreSQL... watch this space... https://github.com/anarazel/postgres/tree/aio

That sounds extremely interesting, would be nice to have more details on this!

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

#244

Post by macdice »

marco_craveiro wrote: post #243
macdice wrote: post #142

Earlier quoted context omitted.

Peope are working on io_uring for PostgreSQL... watch this space... https://github.com/anarazel/postgres/tree/aio

That sounds extremely interesting, would be nice to have more details on this!

Some info here:

https://www.postgresql.org/message-id/flat/20210223100344.ll...

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

#245

Post by marco_craveiro »

macdice wrote: post #244
marco_craveiro wrote: post #243

Earlier quoted context omitted.

That sounds extremely interesting, would be nice to have more details on this!

Some info here: https://www.postgresql.org/message-id/flat/20210223100344.ll...

wow this looks incredible!

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

#246

Post by conradfr »

ComputerGuru wrote: post #148
conradfr wrote: post #73

Earlier quoted context omitted.

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

It does not make sense to run a rdbms in a container in prod; the entire OS is your container.

It makes sense for me using CapRover for my side projects (with multiple envs) all in one cheap server.

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

#247

Post by TheRealKing »

ChrisRackauckas wrote: post #242
TheRealKing wrote: post #235

Earlier quoted context omitted.

Julia has a long way to get there, where Fortran is in terms of stability and maturity, needs approximately 60 years more.

What issue do you have with the use of RecursiveFactorization.jl in DifferentialEquations.jl? I can't think of a maturity issue so I'm curious what you have found, or whether this comment isn't grounded in specifics.

Did my original post even mention RecursiveFactorization.jl or DifferentialEquations.jl? (or is this an implicit package promotion? I do not have issues with them anyway, perhaps great work, have not used them...) Regarding your second point, let's see if the language and its various package APIs remain stable, actively maintained, and backward-compatible just ten years from now, let alone 3 quarters of a century. Such issues do not become visible right away or overnight. I am not against the language, just stating the fact that it has yet to pass the test of time.

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

#248

Post by johnthescott »

ako wrote: post #205
roenxi wrote: post #169

Earlier quoted context omitted.

Postgres is bowing to the inevitable, JSON support is too much in demand. But this is going to be a classic example of bad design. Databases are a bad place to be storing JSON, which is a good interface and a bad storage standard. It is pretty easy to see how JSON will play out: some bright young coder will use JSON because it is easier, then over the course of 12 months discover the benefits of a constrained schema,…

I use the json features of postgres to turn json into relation data. Store all json messages received in a table, then use a materialized view to extract the relevant parts into columns. Works well, and lets me keep the original data around.

roger that.

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

#249

Post by johnthescott »

HideousKojima wrote: post #104
harikb wrote: post #74

Earlier quoted context omitted.

MSSQL ? As in Microsoft SQL Server? I have heard this argument a lot and all the comparisons I have seen are specific benchmarks on specialized hardware. My own personal experience wasn’t anything like the benchmarks

MSSQL still has a few features that set it apart from Postgres. Off the top of my head are Filestream (basically storing files in the database while still having them accessible as files on the filesystem) and temporal tables without the need for extensions. Personally if I were choosing the tech stack for my company I'd still go for Postgres though

pg has had file fw for years: https://www.postgresql.org/docs/13/file-fdw.html

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

#250

Post by osser »

ksec wrote: post #67
rargulati wrote: post #58

What's going to be the vitess of Postgres? Seems to be the "last" missing piece? Or is that not a focus and fit for PG?

I think vitess has some long term goal to also support Postgre.

There are no plans right now.If the Postgres community (or a Postgres user) would like to take this project up, the best way to proceed would be to do it as a fork of Vitess. Once the implementation has been proven in production, a “merge” project can be planned to bring the fork back into upstream.
Post reply on HN