Re: PoC plpgsql - possibility to force custom or generic plan
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>, Pavel Stehule <pavel.stehule@gmail.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Jim Nasby <Jim.Nasby@bluetreble.com>
Date: 2017-04-05T21:41:59Z
Lists: 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
Commits
-
Add plan_cache_mode setting
- f7cb2842bf47 12.0 landed
-
Add some noreturn attributes to help static analyzers
- a044378ce2f6 11.0 cited
-
document when PREPARE uses generic plans
- fab9d1da4a21 9.6.0 cited
-
Redesign the plancache mechanism for more flexibility and efficiency.
- e6faf910d750 9.2.0 cited