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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PoC plpgsql - possibility to force custom or generic plan
Date: 2017-01-24 20:33:56
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

2017-01-24 6:38 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

> Hi
> 2017-01-23 21:59 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:
>> On 1/23/17 2:10 PM, Pavel Stehule wrote:
>>> Comments, notes?
>> +1 on the idea. It'd also be nice if we could expose control of plans for
>> dynamic SQL, though I suspect that's not terribly useful without some kind
>> of global session storage.
>> A couple notes on a quick read-through:
>> Instead of paralleling all the existing namespace stuff, I wonder if it'd
>> be better to create explicit block infrastructure. AFAIK PRAGMAs are going
>> to have a lot of the same requirements (certainly the nesting is the same),
>> and we might want more of this king of stuff in the future. (I've certainly
>> wished I could set a GUC in a plpgsql block and have it's settings revert
>> when exiting the block...)
> I am not sure if I understand. ?? Setting GUC by PRAGMA can work - the
> syntax supports it and GUC API supports nesting. Not sure about exception
> handling - but it should not be problem probably.
> Please, can you show some examples.
>> 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

if (expr->plan == NULL)
exec_prepare_plan(estate, expr, (parallelOK ?

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



>> finit_ would be better named free_.
> good idea
> Regards
> Pavel
>> --
>> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
>> Experts in Analytics, Data Architecture and PostgreSQL
>> Data in Trouble? Get it in Treble!
>> 855-TREBLE2 (855-873-2532)

Attachment Content-Type Size
plpgsql-pragma-plan_cache-01.patch text/x-patch 15.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-01-24 20:38:49 Re: patch: function xmltable
Previous Message Tom Lane 2017-01-24 20:03:04 Re: Improvements in psql hooks for variables