Re: [patch] plproxy v2 - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: [patch] plproxy v2
Date
Msg-id e51f66da0807080913g638b2d51k7e5ee4f9e30067ef@mail.gmail.com
Whole thread Raw
In response to Re: [patch] plproxy v2  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On 7/8/08, Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: "Jaime Casanova"
Date:
Subject: Re: [PATCHES] Extending grant insert on tables to sequences
Next
From: "Marko Kreen"
Date:
Subject: Re: [patch] plproxy v2