Re: Transient plans versus the SPI API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Transient plans versus the SPI API
Date
Msg-id 22031.1312400017@sss.pgh.pa.us
Whole thread Raw
In response to Re: Transient plans versus the SPI API  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Transient plans versus the SPI API
Re: Transient plans versus the SPI API
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.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.  Examples of parameter-value-sensitive decisions that are
made nowhere near the selectivity functions are constraint exclusion and
LIKE pattern to index-qual conversion.  And in none of these cases do we
really know at the bottom level whether a different parameter value will
lead to a significant change in the finished plan.  For instance, if
there's no index for column foo, it is a waste of time to force
replanning just because we have varying selectivity estimates for
"WHERE foo > $1".

I think we'll be a lot better off with the framework discussed last
year: build a generic plan, as well as custom plans for the first few
sets of parameter values, and then observe whether there's a significant
reduction in estimated costs for the custom plans.

But in any case, it's way premature to be debating this until we have
the infrastructure in which we can experiment with different policies.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Transient plans versus the SPI API
Next
From: Tom Lane
Date:
Subject: Re: mosbench revisited