From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] plproxy v2 |
Date: | 2008-07-08 16:13:10 |
Message-ID: | e51f66da0807080913g638b2d51k7e5ee4f9e30067ef@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/8/08, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
> > and potentially SPREAD BY as discussed in:
> >
> > http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/000093.html
>
> That *sounds* cool, but its just the first part of the implementation of
> a massively parallel executor. You'll quickly end up wanting to do
> something else as well. Redistributing data is the hard part of a hard
> problem. I'd steer clear of that. Skytools are good cause they do simple
> things well.
Well, for PL/Proxy it would be the _last_ part. Yes, now the user
can build parallel OLAP executor, but all of this will be up to user.
PL/Proxy itself will stay dumb and simple. It would not need do to
any guesswork, all the data will be provided by user.
The amount of code needed to make the SPREAD work would be minimal,
mostly reactoring of existing code is needed. So it fits the
current design.
The point is - PL/Proxy already executes single query with same
arguments in parallel. With the SPREAD feature it could execute
single query with different arguments in parallel. And the
next step of executing different queries in parallel does not make
sense for PL/Proxy as it's main concept is function-calls not queries.
But ofcourse we can decide we don't want do go that way,
and that's ok also.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2008-07-08 16:16:10 | Re: [patch] plproxy v2 |
Previous Message | Simon Riggs | 2008-07-08 16:11:40 | Re: [patch] plproxy v2 |