Re: PoC plpgsql - possibility to force custom or generic plan

Hi,

I'd like some input from other committers whether we want this. I'm
somewhat doubtful, but don't have particularly strong feelings.

> +
> + <sect2 id="plpgsql-declaration-pragma">
> + <title>Block level PRAGMA</title>
> +
> + <indexterm>
> + <primary>PRAGMA</>
> + <secondary>in PL/pgSQL</>
> + </indexterm>
> +
> + <para>
> + The block level <literal>PRAGMA</literal> allows to change the
> + <application>PL/pgSQL</application> compiler behavior. Currently
> + only <literal>PRAGMA PLAN_CACHE</literal> is supported.

Why are we doing this on a block level?

> +<programlisting>
> +CREATE FUNCTION enforce_fresh_plan(_id text) RETURNS boolean AS $$
> +DECLARE
> + PRAGMA PLAN_CACHE(force_custom_plan);
> +BEGIN
> + -- in this block every embedded query uses one shot plan

*plans

> + <sect3 id="PRAGMA-PLAN_CACHE">
> + <title>PRAGMA PLAN_CACHE</title>
> +
> + <para>
> + The plan cache behavior can be controlled using
> + <literal>PRAGMA PLAN_CACHE</>. This <literal>PRAGMA</> can be used both
> + for whole function or in individual blocks. The following options are

*functions

> + possible: <literal>DEFAULT</literal> - default
> + <application>PL/pgSQL</application> implementation - the system tries
> + to decide between custom plan and generic plan after five query
> + executions, <literal>FORCE_CUSTOM_PLAN</literal> - the chosen execution
> + plan will be the one shot plan - it is specific for every set of
> + used paramaters, <literal>FORCE_GENERIC_PLAN</literal> - the generic
> + plan will be used from the start.

I don't think it's a good idea to explain this here, this'll just get
outdated. I think we should rather have a link here.

> + </para>
> +
> + <para>
> + <indexterm>
> + <primary>PRAGMA PLAN_CACHE</>
> + <secondary>in PL/pgSQL</>
> + </indexterm>
> + The plan for <command>INSERT</command> is always a generic
> plan.

That's this specific insert, right? Should be mentioned, sounds more
generic to me.

> +/* ----------
> + * Returns pointer to current compiler settings
> + * ----------
> + */
> +PLpgSQL_settings *
> +plpgsql_current_settings(void)
> +{
> + return current_settings;
> +}
> +
> +
> +/* ----------
> + * Setup default compiler settings
> + * ----------
> + */
> +void
> +plpgsql_settings_init(PLpgSQL_settings *settings)
> +{
> + current_settings = settings;
> +}

Hm. This is only ever set to &default_settings.

> +/* ----------
> + * Set compiler settings
> + * ----------
> + */
> +void
> +plpgsql_settings_set(PLpgSQL_settings *settings)
> +{
> + PLpgSQL_nsitem *ns_cur = ns_top;
> +
> + /*
> + * Modify settings directly, when ns has local settings data.
> + * When ns uses shared settings, create settings first.
> + */
> + while (ns_cur->itemtype != PLPGSQL_NSTYPE_LABEL)
> + ns_cur = ns_cur->prev;
> +
> + if (ns_cur->local_settings == NULL)
> + {
> + ns_cur->local_settings = palloc(sizeof(PLpgSQL_settings));
> + ns_cur->local_settings->prev = current_settings;
> + current_settings = ns_cur->local_settings;
> + }
> +
> + current_settings->cursor_options = settings->cursor_options;
> +}

This seems like a somewhat weird method. Why do we have a global
settings, when we essentially just want to use something in the current
ns?

- Andres