Skip site navigation (1) Skip section navigation (2)

Re: One-Shot Plans

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: One-Shot Plans
Date: 2011-08-01 09:24:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 14, 2011 at 9:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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.


 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-08-01 09:38:13
Subject: Hot standby and GiST page splits (was Re: WIP: Fast GiST index build)
Previous:From: davegDate: 2011-08-01 03:06:31
Subject: Re: error: could not find pg_class tuple for index 2662

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group