Re: One-Shot Plans

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: One-Shot Plans
Дата
Msg-id CA+U5nM+XjEHr=_5qZq13gBNHQmms9aqthP5BbpEb_HtuEf+Jgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: One-Shot Plans  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: One-Shot Plans  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jun 14, 2011 at 9:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Currently, the planner and executor are mostly independent of each
>> other: the planner doesn't really know when the plan will be executed,
>> and the executor doesn't know how recently the plan was made.
>
>> We can work out the various paths through the traffic cop to see when
>> a plan will be a "one-shot" - planned and then executed immediately,
>> then discarded.
>
> I have already got plans for a significantly more sophisticated approach
> to this.

Hi Tom,

I'd like to move forwards on this capability in this release cycle. I
want to be able to tell whether a plan is a one-shot plan, or not.

If you've got something planned here, please say what it is or
implement directly, so we can avoid me being late on later patches
that depend upon this.

>> In those cases we can take advantage of better optimisations. Most
>> interestingly, we can evaluate stable functions at plan time, to allow
>> us to handle partitioning and partial indexes better.
>
> I don't believe that's correct in detail.

If you can explain why you think this is wrong, I'm happy to remove
the line in evaluate_function() that says

if (funcform->provolatile == PROVOLATILE_STABLE && (context->estimate
|| context->oneshot))

then we're OK to evaluate the function immediately.

Thanks

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: daveg
Дата:
Сообщение: Re: error: could not find pg_class tuple for index 2662
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Hot standby and GiST page splits (was Re: WIP: Fast GiST index build)