Re: PoC plpgsql - possibility to force custom or generic plan
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-01T20:59:10Z
Lists: pgsql-hackers
Attachments
- plpgsql-pragma-plan_cache-02.patch (text/x-patch) patch
Hi 2017-01-24 21:33 GMT+01:00 Pavel Stehule <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 > > Regards > > Pavel > + basic doc Regards Pavel
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