Обсуждение: PREPARE and GUC plan_cache_mode
Our current docs have this text for PREPARE:
Prepared statements can use generic plans rather than re-planning
with each set of supplied EXECUTE values. This occurs immediately
for prepared statements with no parameters; otherwise it occurs
only after five or more executions produce plans whose estimated
cost average (including planning overhead) is more expensive than
the generic plan cost estimate. Once a generic plan is chosen, it
is used for the remaining lifetime of the prepared statement. Using
EXECUTE values which are rare in columns with many duplicates can
generate custom plans that are so much cheaper than the generic
plan, even after adding planning overhead, that the generic plan
might never be used.
There is no mention that PG 12's plan_cache_mode can modify this
behavior. I think this needs a doc patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> Our current docs have this text for PREPARE:
> Prepared statements can use generic plans rather than re-planning
> with each set of supplied EXECUTE values. This occurs immediately
> for prepared statements with no parameters; otherwise it occurs
> only after five or more executions produce plans whose estimated
> cost average (including planning overhead) is more expensive than
> the generic plan cost estimate. Once a generic plan is chosen, it
> is used for the remaining lifetime of the prepared statement. Using
> EXECUTE values which are rare in columns with many duplicates can
> generate custom plans that are so much cheaper than the generic
> plan, even after adding planning overhead, that the generic plan
> might never be used.
> There is no mention that PG 12's plan_cache_mode can modify this
> behavior. I think this needs a doc patch.
Yeah, agreed. I can do it, or do you want to?
regards, tom lane
On Mon, Sep 30, 2019 at 12:05:07PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Our current docs have this text for PREPARE: > > Prepared statements can use generic plans rather than re-planning > > with each set of supplied EXECUTE values. This occurs immediately > > for prepared statements with no parameters; otherwise it occurs > > only after five or more executions produce plans whose estimated > > cost average (including planning overhead) is more expensive than > > the generic plan cost estimate. Once a generic plan is chosen, it > > is used for the remaining lifetime of the prepared statement. Using > > EXECUTE values which are rare in columns with many duplicates can > > generate custom plans that are so much cheaper than the generic > > plan, even after adding planning overhead, that the generic plan > > might never be used. > > > There is no mention that PG 12's plan_cache_mode can modify this > > behavior. I think this needs a doc patch. > > Yeah, agreed. I can do it, or do you want to? Uh, I am feeling I can't do anything with the tree until Friday because of the PG 12 packaging, right? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Sep 30, 2019 at 12:05:07PM -0400, Tom Lane wrote:
>> Yeah, agreed. I can do it, or do you want to?
> Uh, I am feeling I can't do anything with the tree until Friday because
> of the PG 12 packaging, right?
There's not a freeze on docs, as far as I'm concerned. I'm working
on it right now.
regards, tom lane