Re: PoC plpgsql - possibility to force custom or generic plan - Mailing list pgsql-hackers

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