Simon Riggs <simon@2ndQuadrant.com> writes:
> On Tue, Jun 14, 2011 at 9:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I have already got plans for a significantly more sophisticated approach
>> to this.
> 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.
Yes, I'm planning to do something about this for 9.2, hopefully before
the next commitfest starts. See prior discussions --- what I have in
mind is to generate one-shot plans and test whether they're predicted to
be significantly cheaper than a generic plan. After a certain number of
failures to be better than generic, we'd give up and just use the
generic plan every time. Another heuristic that might be worth thinking
about is to not even bother with a generic plan until the N'th execution
of a prepared statement, for some N that's small but more than 1. We
already have that behavior for certain cases associated with particular
FE protocol usages, but not for plpgsql statements as an example.
>> 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
I'm concerned about which snapshot the function is executed against.
regards, tom lane
