From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04-06 18:32:35 |
Message-ID: | CAFj8pRDDtruyC10MOFUbA1FDsgQ1F+6XinDdZ9f3pY2GBr6rEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-04-06 12:30 GMT+02:00 Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>:
>
>
> On 04/05/2017 05:41 PM, Andres Freund wrote:
> > On 2017-04-05 17:22:34 -0400, Tom Lane wrote:
> >> Andres Freund <andres(at)anarazel(dot)de> writes:
> >>> I'd like some input from other committers whether we want this. I'm
> >>> somewhat doubtful, but don't have particularly strong feelings.
> >> I don't really want to expose the workings of the plancache at user
> level.
> >> The heuristics it uses certainly need work, but it'll get hard to change
> >> those once there are SQL features depending on it.
> >>
> >> Also, as you note, there are debatable design decisions in this
> particular
> >> patch. There are already a couple of ways in which control knobs can be
> >> attached to plgsql functions (i.e. custom GUCs and the comp_option
> stuff),
> >> so why is this patch wanting to invent yet another fundamental
> mechanism?
> >> And I'm not very happy about it imposing a new reserved keyword, either.
> >>
> >> A bigger-picture question is why we'd only provide such functionality
> >> in plpgsql, and not for other uses of prepared plans.
> >>
> >> Lastly, it doesn't look to me like the test cases prove anything at all
> >> about whether the feature does what it's claimed to.
> > That echoes my perception - so let's move this to the next CF? It's not
> > like this patch has been pending for very long.
> >
>
>
> Or just Return with Feedback.
>
> ISTM before we revisit this we need agreement on a design.
>
I am open to any ideas - there are some my start points
1. the possibility to disable plan cache is real request
2. can be useful if we are able to control plan cache inside function - the
mix of settings is real case too
3. GUC are useless - nobody would to disable plan cache globally
I like to see any proposals about syntax or implementation.
Using PRAGMA is one variant - introduced by PLpgSQL origin - Ada language.
The PRAGMA syntax can be used for PRAGMA autonomous with well known syntax.
It scales well - it supports function, block or command level.
I invite any discussion now or in start of new release cycle.
Regards
Pavel
> cheers
>
> andrew
>
>
> --
> Andrew Dunstan https://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2017-04-06 18:33:46 | Re: increasing the default WAL segment size |
Previous Message | Peter Eisentraut | 2017-04-06 18:31:53 | Re: Functions Immutable but not parallel safe? |