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

231–240 of 254 posts

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

#231

Post by whatshisface »

tgv wrote: post #200
zdragnar wrote: post #161

Earlier quoted context omitted.

It isn't really a surprise in this case since both ethnic Mongolians and those with Downs syndrome are not in many Americans' social circles. "Almost all" does sound like a bit of a surprise, but thinking back on it the only one I know for a fact I heard for the first time outside of a corrective context was my elder uncles friends who enjoyed self-depreciating jokes, usually with slurs for eastern Europeans in them.…

Mongo and mongol don't have a close relationship: the final syllable is entirely different.

It's implied that someone is going around calling people with Down's syndrome "Mongos." "Mongol" is an actual non-offensive[0] word which means, unsurprisingly, someone who can trace their lineage back to the area around Mongolia.

[0] https://en.wikipedia.org/wiki/Mongols (If it's used descriptively on Wikipedia, it's probably not considered offensive.)

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

#232

Post by derefr »

megous wrote: post #172
derefr wrote: post #165

Earlier quoted context omitted.

> Is there even a function that would convert JSON encoded "string" to text it represents in postgresql? I didn't find it. Oddly, no, there's no specific function for taking a root-level scalar JSON term (like '"foo"'::jsonb), and extracting said scalar to its equivalent native Postgres type. You can still do it (for extracting to text, at least), but you have to use a 'vacuous' path-navigation to accomplish it, so i…

Thanks for the idea. This is a bit shorter: SELECT '"foo"'::jsonb #>>'{}'; But yeah: SELECT jsonb_col['prop1']#>>'{}' FROM ...; looks a bit meh. And custom right unary operators are on the way out, so one can't even create one for this use case. Anyway, for fun: create function deref_jsonb(jsonb) returns text as $$ begin return $1#>>'{}'; end $$ language plpgsql; CREATE OPERATOR # ( leftarg = jsonb, function = deref_…

You could also take advantage of PG's function/field equivalence:

           -- equivalent to deref_jsonb('"sdfasdf"'::jsonb)
    select ('"sdfasdf"'::jsonb).deref_jsonb;
(I'd suggest naming the function "inner_text", for familiarity to JS devs :P)

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

#233

Post by megous »

derefr wrote: post #232
megous wrote: post #172

Earlier quoted context omitted.

Thanks for the idea. This is a bit shorter: SELECT '"foo"'::jsonb #>>'{}'; But yeah: SELECT jsonb_col['prop1']#>>'{}' FROM ...; looks a bit meh. And custom right unary operators are on the way out, so one can't even create one for this use case. Anyway, for fun: create function deref_jsonb(jsonb) returns text as $$ begin return $1#>>'{}'; end $$ language plpgsql; CREATE OPERATOR # ( leftarg = jsonb, function = deref_…

You could also take advantage of PG's function/field equivalence: -- equivalent to deref_jsonb('"sdfasdf"'::jsonb) select ('"sdfasdf"'::jsonb).deref_jsonb; (I'd suggest naming the function "inner_text", for familiarity to JS devs :P)

Oh my. :) There's always some quirky little thing to learn about PostgreSQL, lol.

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

#234

Post by ChrisRackauckas »

yakubin wrote: post #230
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…

> Not an expert, but it is my understanding that Julia is becoming an ever more serious competitor day by day. And Julia uses BLAS which is written in Fortan.

Not necessarily. All of the DifferentialEquations.jl defaults use pure Julia BLASes which outperform the Fortran BLASes. Mainly, RecursiveFactorization.jl and Octavian.jl, which tend to match or outperform MKL and OpenBLAS on our benchmarking computers, form our workhorse.

https://raw.githubusercontent.com/JuliaLinearAlgebra/Octavia...

https://github.com/JuliaLinearAlgebra/Octavian.jl

https://github.com/YingboMa/RecursiveFactorization.jl

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

#235

Post by TheRealKing »

nsajko wrote: post #225
yakubin wrote: post #10

Earlier quoted context omitted.

Fortran for linear algebra software. Excel for business spreadsheets. Java for enterprise server software.

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

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

#236

Post by hu3 »

pgaddict wrote: post #212
developer2 wrote: post #203

Earlier quoted context omitted.

And this right here is why PostgreSQL will never overtake MySQL and its forks. The entire industry is sick of these excuses regarding process-per-client instead of a proper multi-threaded model. There may have been a valid argument for this 15 years ago, but not anymore. Your definition of "reasonable number of long-lived connections" is anything but reasonable. Then "connection pools address a lot of the other cases…

I disagree, for a number of reasons. Firstly, it's not the goal of the PostgreSQL project to overtake MySQL or other databases, but to serve the existing/new users. This also means we're investing the development effort in a the highest benefit / effort ratio. Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort rati…

> Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort ratio is so utterly awful no one is going to do it.

Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are gaining marketshare over Apache httpd.

I love PostgreSQL and don't want to see it becoming the next Apache httpd, slowly but surely fading. Perhaps FAANGs could fund such refactor.

Perhaps a cheaper solution was to incorporate pgBouncer inside PostgreSQL so it would naturally sit in front of PostreSQL in the default installation without extra configuration.

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

#237

Post by pgaddict »

hu3 wrote: post #236
pgaddict wrote: post #212

Earlier quoted context omitted.

I disagree, for a number of reasons. Firstly, it's not the goal of the PostgreSQL project to overtake MySQL or other databases, but to serve the existing/new users. This also means we're investing the development effort in a the highest benefit / effort ratio. Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort rati…

> Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort ratio is so utterly awful no one is going to do it. Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are…

> Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are gaining marketshare over Apache httpd.

Maybe, we'll see.

It however assumes the other (thread-based) architecture is somewhat universally better, and I doubt that's how it works. It might help the workloads actually requiring many connections to some extent, but it's also likely to hurt other workloads for which the current architecture works just fine.

But let's assume we decide to do that - such change would be a massive shift in programming paradigm (both internally and for extensions developed by 3rd parties) and would probably require multiple years. That's a huge investment of time/effort, with a lot of complexity, risks and very limited benefits until it's done. I'd bet there'll always be a feature with better cost/benefit ratio.

So reworking the other architecture might actually gain us some users but loose others, and drain insane amount of development resources.

> Perhaps a cheaper solution was to incorporate pgBouncer inside PostgreSQL so it would naturally sit in front of PostreSQL in the default installation without extra configuration.

Yes, I already mentioned that's quite likely to happen. There has already been a patch / project to do exactly that, but it didn't make it into PG14.

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

#238

Post by fshr »

zaius wrote: post #177
gogopuppygogo wrote: post #103

Earlier quoted context omitted.

Cockroach is the worst brand for a database ever. Even Croach would be a massive branding improvement. This is similar to how gimp is a terrible brand.

It’s no coincidence - the names for Cockroach and GIMP were coined by the same person https://en.m.wikipedia.org/wiki/Spencer_Kimball_(computer_pr...

Well that explains a lot. Imagine the success of all his work had it had better branding.

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

#239

Post by hu3 »

pgaddict wrote: post #237
hu3 wrote: post #236

Earlier quoted context omitted.

> Even if switching from process-based to thread-based model improved the per-connection overhead, the amount of work needed is so huge the benefit / effort ratio is so utterly awful no one is going to do it. Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are…

> Then other products will emerge and overtake some of PostreSQL's marketshare in the long run. It's already happening in fact. Just like more efficient and easier to configure webservers like nginx and caddy are gaining marketshare over Apache httpd. Maybe, we'll see. It however assumes the other (thread-based) architecture is somewhat universally better, and I doubt that's how it works. It might help the workloads…

> There has already been a patch / project to do exactly that, but it didn't make it into PG14.

That's great to hear!

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

#240

Post by randomswede »

whatshisface wrote: post #231
tgv wrote: post #200

Earlier quoted context omitted.

Mongo and mongol don't have a close relationship: the final syllable is entirely different.

It's implied that someone is going around calling people with Down's syndrome "Mongos." "Mongol" is an actual non-offensive[0] word which means, unsurprisingly, someone who can trace their lineage back to the area around Mongolia. [0] https://en.wikipedia.org/wiki/Mongols (If it's used descriptively on Wikipedia, it's probably not considered offensive.)

Mongol is not (as far as I am aware) an offensive word. Mongoloid[0] (which "mongo" is a shortened form of) in reference to people with Down Syndrome, definitely is.

My pet theory is that the database is named after a character in "Blazing Saddles", and I want to be able to store candy in it.

[0] https://en.wikipedia.org/wiki/Down_syndrome#Name

Post reply on HN