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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Дата
Msg-id CAFj8pRAH3yRvfqeYoLbKRNBA97iwUyWDw-5Fb6GnMSrg19AMpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (David Steele <david@pgmasters.net>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem