Re: PoC plpgsql - possibility to force custom or generic plan
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
Jim Nasby <Jim.Nasby@bluetreble.com>
Date: 2017-03-16T16:15:42Z
Lists: pgsql-hackers
On 2/1/17 3:59 PM, Pavel Stehule wrote: > Hi > > 2017-01-24 21:33 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com > <mailto:pavel.stehule@gmail.com>>: > > Perhaps that's as simple as renaming all the existing _ns_* > functions to _block_ and then adding support for pragmas... > > Since you're adding cursor_options to PLpgSQL_expr it should > probably be removed as an option to exec_*. > > I have to recheck it. Some cursor options going from dynamic > cursor variables and are related to dynamic query - not query > that creates query string. > > hmm .. so current state is better due using options like > CURSOR_OPT_PARALLEL_OK > > if (expr->plan == NULL) > exec_prepare_plan(estate, expr, (parallelOK ? > CURSOR_OPT_PARALLEL_OK : 0) | > expr->cursor_options); > > This options is not permanent feature of expression - and then I > cannot to remove cursor_option argument from exec_* > > I did minor cleaning - remove cursor_options from plpgsql_var > > + basic doc This patch still applies cleanly and compiles at cccbdde. Any reviewers want to have a look? -- -David david@pgmasters.net
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