Horton

Re: PoC plpgsql - possibility to force custom or generic plan

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, Daniel Gustafsson <daniel@yesql.se>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Jim Nasby <Jim.Nasby@bluetreble.com>
Date: 2017-09-19T16:45:09Z
Lists: pgsql-hackers 
2017-09-19 18:33 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:

> On Mon, Sep 18, 2017 at 11:46 PM, Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
> > There is possibility to introduce new compile option #option to disable
> plan
> > cache on function scope. Do you think so it is acceptable solution? It is
> > step forward.
>
> You can already set a GUC with function scope.  I'm not getting your point.
>

yes, it is true. But implementation of #option is limited to PLpgSQL - so
there is not any too much questions - GUC is global - there is lot of
points:

* what is correct impact on PREPARE
* what is correct impact on EXECUTE
* what should be done if this GUC is changed ..

Regards

Pavel


> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Commits

  1. Add plan_cache_mode setting

  2. Add some noreturn attributes to help static analyzers

  3. document when PREPARE uses generic plans

  4. Redesign the plancache mechanism for more flexibility and efficiency.