From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Shay Rojansky <roji(at)roji(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cached/global query plans, autopreparation |
Date: | 2018-03-02 20:38:43 |
Message-ID: | 20180302203843.5y6tduumbwdiyeen@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote:
> Postgres uses a conservative method for reusing plans with previous
> constants, as described in the PREPARE manual page:
>
> https://www.postgresql.org/docs/10/static/sql-prepare.html
> 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.
>
> While I have heard people complain about how other databases cache
> prepare plans, I have heard few complaints about the Postgres approach,
> and I haven't even heard of people asking to control the documented "five
> or more" behavior.
This *constantly* is a problem.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-03-02 20:41:57 | Re: [HACKERS] Creating backup history files for backups taken from standbys |
Previous Message | Bruce Momjian | 2018-03-02 20:29:09 | Re: Cached/global query plans, autopreparation |