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

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: PoC plpgsql - possibility to force custom or generic plan
Date: 2017-03-18 18:30:01
Message-ID: 72a70e17-84eb-8939-7b2f-ec088f549e2f@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16/03/17 17:15, David Steele wrote:
> On 2/1/17 3:59 PM, Pavel Stehule wrote:
>> Hi
>>
>> 2017-01-24 21:33 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com
>> <mailto:pavel(dot)stehule(at)gmail(dot)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?
>

I'll bite.

I agree with Jim that it's not very nice to add yet another
block/ns-like layer. I don't see why pragma could not be added to either
PLpgSQL_stmt_block (yes pragma can be for whole function but function
body is represented by PLpgSQL_stmt_block as well so no issue there), or
to namespace code. In namespace since they are used for other thing
there would be bit of unnecessary propagation but it's 8bytes per
namespace, does not seem all that much.

My preference would be to add it to PLpgSQL_stmt_block (unless we plan
to add posibility to add pragmas for other loops and other things) but I
am not sure if current block is easily (and in a fast way) accessible
from all places where it's needed. Maybe the needed info could be pushed
to estate from PLpgSQL_stmt_block during the execution.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Elvis Pranskevichus 2017-03-18 19:01:42 Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Previous Message Pavel Stehule 2017-03-18 18:22:28 Re: New CORRESPONDING clause design