On some operating systems, like Windows and Solaris, processes are expensive, while threads are cheap, so to speak. this is not the case in Linux or BSD, where the differences are much smaller, and the multi-process design suffers no great disadvantage.
Even on Windows or Solaris you can use techniques like persistent connections or connection pooling to eliminate the process overhead.
Actually, if it were converted to multi-threaded tomorrow, it would still be true, because the postgresql engine isn't designed to split off queries into constituent parts to be executed by seperate threads or processes. Conversely, if one wished to implement it, one could likely patch postgresql to break up parts of queries to different child processes of the current child process (grand child processes so to speak) that would allow a query to hit multiple CPUs.
I would be curious as to what this would actually gain. Of course there
are corner cases but I rarely find that it is the CPU that is doing all the work, thus splitting the query may not do you any good.
In theory I guess being able to break it up and execute it to different CPUs could cause the results to process faster, but I wonder if it would be a large enough benefit to even notice?
"We also provide MySQL Server as an embedded multi-threaded library that you can link into your application to get a smaller, faster, easier-to-manage product."
Do PostgreSQL offer anything similar?
No, it isn't really designed to do that. Like Oracle also is not a database you would Embed.
pick PostgreSQL, it's generally considered a bad thing to have a database crash mid transaction. PostgreSQL is more robust about crash recovery, but still...
That's another subject that shows up every x months, an embedded version of PostgreSQL. Basically, the suggestion is to use something like SQLlite, which is built to be embedded, and therefore has a much lower footprint than PostgreSQL could ever hope to achieve. No one wants their embedded library using up gobs of RAM and disk space when it's just handling one thread / process doing one thing. It's like delivering Pizzas with a Ferrari, you could do it, it just eouldn't make a lot of sense.
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
-- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
