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