Re: [patch] plproxy v2

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: [patch] plproxy v2
Дата
Msg-id e51f66da0807080913g638b2d51k7e5ee4f9e30067ef@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [patch] plproxy v2  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jaime Casanova"
Дата:
Сообщение: Re: [PATCHES] Extending grant insert on tables to sequences
Следующее
От: "Marko Kreen"
Дата:
Сообщение: Re: [patch] plproxy v2