From: Christopher Browne <cbbrowne@acm.org>
Subject: Re: does postgresql execute unions in parallel?
Date: Fri, 26 Sep 2003 16:28:23 -0400
Organization: Hub.Org Networking Services
Lines: 33
Message-ID: <604qyz2t20.fsf@dev6.int.libertyrms.info>
References: <bkv76m$h4f$1@news.hub.org> <3F749A83.30001@bigfoot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Rational FORTRAN, linux)
Cancel-Lock: sha1:5L5HQ8GNVo2gxjkcqlo1IKlKyWw=
To: pgsql-sql@postgresql.org

mendola@bigfoot.com (Gaetano Mendola) writes:
> teknokrat wrote:
>> If I have several selects joined with unions does postgresql
>> execute the concurrently or not?
>
> nope.

I was talking with Jan about that very idea yesterday; this would seem
to be the place where PostgreSQL might take some (possibly even nearly
magical :-)) benefit from threading.

The usual way that people expect to use threading is for each
connection to have a thread.

If, instead, every _join_ had a thread, that would allow producers of
data to look for their data quasi-independently, passing result sets
upwards towards the return set to whatever thread was waiting to
consume the data.  

This would allow one complex query to take over a whole horde of
processors :-).

The "magic" part would be if the system decided, "The SEQ SCAN on the
table I'm looking at is a big one; let's split it into 4 chunks, doing
a virtual UNION ALL, and thereby filter bits of it in parallel on 4
CPUs."  That would provide many of the benefits Informix claimed from
"fragmentation" without having to fragment the table :-).
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/lsf.html
Rules of the  Evil Overlord #187. "I will not  hold lavish banquets in
the middle of  a famine. The good PR among the  guests doesn't make up
for the bad PR among the masses."  <http://www.eviloverlord.com/>