Re: Transient plans versus the SPI API

[ getting back to the planner finally ]

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Wed, Aug 3, 2011 at 8:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>>> I think its possible to tell automatically whether we need to replan
>>> always or not based upon the path we take through selectivity
>>> functions.

>> I don't really believe that, or at least I think it would only detect a
>> few cases.

> The problem there is which executions we build custom plans for. That
> turns the problem into a sampling issue and you'll only fix the
> problems that occur with a frequency to match your sampling pattern
> and rate. Examples of situations where it won't help.

Sure, this is not going to solve every problem we have with the
planner. What it is intended to solve is cases where someone is trying
to use the prepared-plan mechanisms but he would be a lot better off
with parameter-value-specific plans. In particular:

> * plans that vary by table size will be about the same in the first 5
> executions. After large number of executions, things go bad.

This is a red herring. The plancache code already arranges to replan
every time the relevant table stats are updated by autovacuum, which
should certainly happen from time to time if the table's contents are
changing materially. If you're thinking in terms of plans being "stale"
then you're worrying about a long-since-solved problem.

regards, tom lane