On Thu, Jan 26, 2012 at 3:52 PM, Rodrigo E. De León Plicet
<rdeleonp@gmail.com> wrote:
> Quote:
>
> ======================================================================
>
> This thread
>
> http://postgresql.1045698.n5.nabble.com/Multithread-Query-Planner-td5143643.html
>
> was mentioned in a performance sub-group posting. Give it a read.
>
> Back? It means, so far as I can see, that PG is toast. It will fall
> down to being the cheap and dirty alternative to MySql, which even
> has, at least two, multi-threaded engines. DB2 switched it's *nix
> engine to threads from processes with release 9.5. Oracle claims it
> for releases going back to 7 (I haven't tried to determine which parts
> or applications; Larry has bought so many tchochtkes over the
> years...). SQL Server is threaded.
>
> Given that cpu's are breeding threads faster than cores,
> PG will fall into irrelevance.
The author of that post apparently doesn't understand that even though
postgresql hasn't 'switched to threads', it can still do more than one
thing at once. Each process is itself an execution thread. A
multi-threaded query planner is perfectly possible in postgresql
architecture -- however each one must reside in it's own process and
you have to use shared memory instead instead of pthreads and locking.
Big whoop. The only thing at stake with a multi threaded planner is
optimizing single user tasks which is, while important, a niche
optimization. PostgreSQL is for more scalable than mysql for
multi-user loads and the gap is increasing.
merlin