Re: [patch] plproxy v2

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

In response to

Browse pgsql-hackers by date

  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