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

PostgreSQL reconsiders its process-based model

lwn.net

Post reply on HN
Print view View original

241–250 of 377 posts

Re: PostgreSQL reconsiders its process-based model

#241

Post by SoftTalker »

abhibeckert wrote: post #224
eclipticplane wrote: post #72

For the record, I think this will be a disaster. There is far too much code that will get broken, largely silently, and much of it is not under our control. regards, tom lane (via https://lwn.net/ml/pgsql-hackers/4178104.1685978307@sss.pgh.... ) If Tom Lane says it will be a disaster, I believe it will be a disaster.

Reminds me of PHP 6... For those who don't follow PHP closely - that version was an attempted refactor of the string implementation which essentially shut down nearly all work on PHP for a decade, stagnating the language until it became pretty terrible compared to other options. They finally gave up and started work on PHP 7 which uses the (perfectly good) PHP 5 strings. Ten years of wasted time by the best internal…

Things You Should Never Do

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

An oldie but a goodie

Re: PostgreSQL reconsiders its process-based model

#243

Post by doctor_eval »

I know I’m probably being naive about this, but is it stupid to ask if there’s a way to make multi process work better on Linux - rather than “fixing” PG?

I feel like the thread vs process thing is one of those pendulums/fads that comes and goes. I’d hate to see PG go down a rabbit hole only to discover the OS could be modified to make things go better.

(I understand not all PG instances run on Linux, just using it as an example)

Re: PostgreSQL reconsiders its process-based model

#244

Post by chmod775 »

doctor_eval wrote: post #243

I know I’m probably being naive about this, but is it stupid to ask if there’s a way to make multi process work better on Linux - rather than “fixing” PG? I feel like the thread vs process thing is one of those pendulums/fads that comes and goes. I’d hate to see PG go down a rabbit hole only to discover the OS could be modified to make things go better. (I understand not all PG instances run on Linux, just using it a…

> I feel like the thread vs process thing is one of those pendulums/fads that comes and goes.

In this context threads can be understood as processes that share the same address space and vice-versa processes as threads with separate address space.

One gives you isolation, the other convenience and performance. Either can be desirable.

What would you change about this?

Re: PostgreSQL reconsiders its process-based model

#245

Post by dikei »

doctor_eval wrote: post #243

I know I’m probably being naive about this, but is it stupid to ask if there’s a way to make multi process work better on Linux - rather than “fixing” PG? I feel like the thread vs process thing is one of those pendulums/fads that comes and goes. I’d hate to see PG go down a rabbit hole only to discover the OS could be modified to make things go better. (I understand not all PG instances run on Linux, just using it a…

That'll likely be an even bigger task, and harder to get into mainline kernel.

Linux multi-process is already pretty efficient compared to Windows. However, multi-process is inherently less efficient than multi-thread due to more safety predicates / isolation guaranteed by the kernel, I feel lowering it might lead to more security issues, similar to how Hyper Threading triggered a bunch of issues with Intel Processors.

Re: PostgreSQL reconsiders its process-based model

#246

Post by nonethewiser »

BoardsOfCanada wrote: post #20

I recently looked through the source code of postgresql and every source files starts with a (really good) description of what the file is supposed to do, which made it really easy to get in to the code compared to other open source projects I've seen. So thanks for that.

Uncle Bob hates this.

Re: PostgreSQL reconsiders its process-based model

#247

Post by cakoose »

junon wrote: post #230
remexre wrote: post #212

Earlier quoted context omitted.

Wouldn't those statics also be slated for removal with this change?

At most they'd be determined to be read only constants that are inlined during constant folding. This includes most integral sized / typed scalar values that fit into registers for the most part, and nothing you've taken the address of either - those remain as static data.

I think there might be a terminology mix-up here. In C, a global variable with the `static` keyword is is still mutable. So it typically can't be constant-folded/inlined.

The `static` modifier in that context just means that the symbol is not exported, so other ".c" files can't access it.

Re: PostgreSQL reconsiders its process-based model

#250

Post by doctor_eval »

dikei wrote: post #245
doctor_eval wrote: post #243

I know I’m probably being naive about this, but is it stupid to ask if there’s a way to make multi process work better on Linux - rather than “fixing” PG? I feel like the thread vs process thing is one of those pendulums/fads that comes and goes. I’d hate to see PG go down a rabbit hole only to discover the OS could be modified to make things go better. (I understand not all PG instances run on Linux, just using it a…

That'll likely be an even bigger task, and harder to get into mainline kernel. Linux multi-process is already pretty efficient compared to Windows. However, multi-process is inherently less efficient than multi-thread due to more safety predicates / isolation guaranteed by the kernel, I feel lowering it might lead to more security issues, similar to how Hyper Threading triggered a bunch of issues with Intel Processor…

Right - yeah I was really just wondering if some of the safety predicates could be reduced when there is a relationship between processes, such as the mitigations against cache attacks. I think the cache misses caused by multi-process were one of the reasons given that it's slower than threading. But I don't understand why this is necessarily the case given that the shared memory and executable text ultimately refer to the same data. But I suppose this would need to work with processor affinity and other elements to prevent the cache being knocked around by non-PG processes, and I guess this is one place where it starts getting complicated.

That said, please understand that I'm just being curious - I really don't know what I'm talking about, I haven't built a Linux kernel or dabbled in Unix internals in like 20 years, but thanks for replying :) Postgresql is my favourite open source project and I'm spooked by the threading naysayers.

Post reply on HN