Re: PoC plpgsql - possibility to force custom or genericplan - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PoC plpgsql - possibility to force custom or genericplan
Date
Msg-id 20170405214159.zphqngn4tsjifwme@alap3.anarazel.de
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: PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: PoC plpgsql - possibility to force custom or genericplan  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
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.

- Andres



pgsql-hackers by date:

Previous
From: Mike Palmiotto
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: David Rowley
Date:
Subject: Re: multivariate statistics (v25)