Re: PoC plpgsql - possibility to force custom or generic plan
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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:22:34Z
Lists: pgsql-hackers
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. regards, tom lane
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