From: Vitalii Tymchyshyn <tivv00@gmail.com>
To: Chris Browne <cbbrowne@acm.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: getting the most of out multi-core systems for repeated complex SELECT statements
Date: Mon, 07 Feb 2011 12:02:57 +0200
Message-ID: <4D4FC351.4000105@gmail.com> (raw)
In-Reply-To: <87lj1v1jep.fsf@cbbrowne.afilias-int.info>
References: <20110203105704.BAX82905@ms14.lnh.mail.rcn.net>
<87lj1v1jep.fsf@cbbrowne.afilias-int.info>
Hi, all
My small thoughts about parallelizing single query.
AFAIK in the cases where it is needed, there is usually one single
operation that takes a lot of CPU, e.g. hashing or sorting. And this are
usually tasks that has well known algorithms to parallelize.
The main problem, as for me, is thread safety. First of all, operations
that are going to be parallelized, must be thread safe. Then functions
and procedures they call must be thread safe too. So, a marker for a
procedure must be introduced and all standard ones should be
checked/fixed for parallel processing with marker set.
Then, one should not forget optimizer checks for when to introduce
parallelizing. How should it be accounted in the query plan? Should it
influence optimizer decisions (should it count CPU or wall time when
optimizing query plan)?
Or can it simply be used by an operation when it can see it will benefit
from it.
Best regards, Vitalii Tymchyshyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tivv00@gmail.com, cbbrowne@acm.org
Subject: Re: getting the most of out multi-core systems for repeated complex SELECT statements
In-Reply-To: <4D4FC351.4000105@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox