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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: PoC plpgsql - possibility to force custom or generic plan
Date: 2017-10-12 09:31:29
Message-ID: CAFj8pRAXd9hsSXZ-7iZQLTDw8S3=ycF-GfZ2aC76vh77JJBv0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

2017-09-19 20:49 GMT+02:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Tue, Sep 19, 2017 at 1:37 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > On Tue, Sep 19, 2017 at 12:45 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >>> 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 ..
> >
> > For better or for worse, as a project we've settled on GUCs as a way
> > to control behavior. I think it makes more sense to try to apply that
> > option to new behaviors we want to control than to invent some new
> > system.
>
> This seems very sensible.
>
> We also have infrastructure at the SQL level (SET) to manage the GUC.
> Tom upthread (for pretty good reasons) extending SET to pl/pgsql
> specific scoping but TBH I'm struggling as to why we need to implement
> new syntax for this; the only thing missing is being able to scope SET
> statements to a code block FWICT.
>
>
here is a GUC based patch for plancache controlling. Looks so this code is
working.

It is hard to create regress tests. Any ideas?

Regards

Pavel

> merlin
>

Attachment Content-Type Size
guc-plancache_mode.patch text/x-patch 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KES 2017-10-12 10:01:06 Re: BUG #14850: Implement optinal additinal parameter for 'justify' date/time function
Previous Message Arthur Zakirov 2017-10-12 09:15:43 Re: BUG #14850: Implement optinal additinal parameter for 'justify' date/time function