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

From Pavel Stehule
Subject Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Date
Msg-id CAFj8pRAH3yRvfqeYoLbKRNBA97iwUyWDw-5Fb6GnMSrg19AMpg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (David Steele <david@pgmasters.net>)
List pgsql-hackers
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
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Next
From: Claudio Freire
Date:
Subject: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem