Date: Mon, 30 Sep 2019 12:47:34 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Subject: Re: PREPARE and GUC plan_cache_mode
Message-ID: <20190930164734.GD8385@momjian.us>
References: <20190930155505.GA21095@momjian.us>
 <13155.1569859507@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <13155.1569859507@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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 +