Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Date
Msg-id CAFj8pRDDtruyC10MOFUbA1FDsgQ1F+6XinDdZ9f3pY2GBr6rEw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


2017-04-06 12:30 GMT+02:00 Andrew Dunstan <andrew.dunstan@2ndquadrant.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@anarazel.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Functions Immutable but not parallel safe?
Next
From: David Steele
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size