From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: PREPARE and GUC plan_cache_mode |
Date: | 2019-09-30 16:47:34 |
Message-ID: | 20190930164734.GD8385@momjian.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Mon, Sep 30, 2019 at 12:05:07PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-09-30 17:18:08 | Re: PREPARE and GUC plan_cache_mode |
Previous Message | Tom Lane | 2019-09-30 16:05:07 | Re: PREPARE and GUC plan_cache_mode |