Re: Parallel queries

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Michael Ansley <Michael(dot)Ansley(at)intec-telecom-systems(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel queries
Date: 2001-02-06 05:02:55
Message-ID: 3A7F857F.BF11B880@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> How hard would it be to get a back end to hand off parts of a query
> tree to other back ends (which it created), and then collate the
> results, and take it from there? Obviously, it would only do this
> under certain conditions, specifically, if it was compiled in to the
> server, and the query tree in question had a particular profile, i.e.:
> lent itself to parallel processing. But surely it couldn't be that
> difficult to get a back end to hand off, say, a sub-select sub-tree,
> or UNION sub-trees. Under heavy loads with the right hardware, this
> could gain significant performance improvement.

Right. This would help speed up some single-client queries on SMP
machines (we already scale will with multiple clients on SMP machines).
This could perhaps be solved by threading each client backend, or, as
you suggest, by spawning entirely new processes (which would easily ??
generalize into distributed database support). Bring it up after 7.1 is
released (though there may be enough hoops to jump through that it would
not be in 7.2; not certain yet).

All imho of course, though we've had a few discussions off-list to help
get us thinking about it for planning purposes.

I would assume that it will take a few folks working together to get
this to fly, but feel free to give it a go on your own.

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Kirkpatrick 2001-02-06 05:21:49 Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....
Previous Message Ryan Kirkpatrick 2001-02-06 04:59:13 Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....