Re: explain and PARAM_EXEC

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: explain and PARAM_EXEC
Дата
Msg-id 603c8f071002200510x63410e75r1648c5f822bfa009@mail.gmail.com
обсуждение исходный текст
Ответ на Re: explain and PARAM_EXEC  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы parallelizing subplan execution (was: explain and PARAM_EXEC)  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: explain and PARAM_EXEC  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Feb 20, 2010 at 6:57 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> It's really not much different from a function call with subplans as
>> functions.  The PARAM_EXEC stuff looks just like 1950's era
>> non-reentrant function parameter passing mechanisms, back before anybody
>> had thought of recursive functions and they passed a function's
>> parameters in fixed storage locations.  It's okay for this because
>> subplan trees are never recursive ...
>
> <hand waving alert>
>
> How much does this stuff is dependent on the current state of the
> backend?

A whole lot.

> Ok that's a far stretch from the question at hand, but would that be a
> plausible approach to have parallel queries in PostgreSQL ?

This is really a topic for another thread, but at 100,000 feet it
seems to me that the hardest question is - how will you decide which
operations to parallelize in the first place?  Actually making it
happen is really hard, too, of course, but even to get that that point
you have to have some model for what types of operations it makes
sense to parallelize and how you're going to decide when it's a win.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: explain and PARAM_EXEC
Следующее
От: Robert Haas
Дата:
Сообщение: Re: explain and PARAM_EXEC