DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	b=lVng5yWFYJP8a3GeyIXh2pdquBHpZBHtEtJa/7VMx4RjdgveqCV5zFRC/EqEbhQxat
	JuIRcDHhTnYhg6PRNukyIdecG8f5FoHAbOQLlws2NpG5x16zxfBlZlubfULKrvWYFjNO
	bR6ALqBCluPUOmDZ7fbxGB+UuNF/S3pW1sEvM=
Message-ID: <4D4FC351.4000105@gmail.com>
Date: Mon, 07 Feb 2011 12:02:57 +0200
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
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
References: <20110203105704.BAX82905@ms14.lnh.mail.rcn.net>
	<87lj1v1jep.fsf@cbbrowne.afilias-int.info>
In-Reply-To: <87lj1v1jep.fsf@cbbrowne.afilias-int.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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