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 CAFj8pRA9adNmiqkeSQLktebq2qBojsVCaKdnhpTf0CvA1Wt+cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


2017-09-11 14:44 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 9/8/17 13:14, Simon Riggs wrote:
>> 2. Allow a SET to apply only for a single statement
>> SET guc1 = x, guc2 = y FOR stmt
>> e.g. SET max_parallel_workers = 4 FOR SELECT count(*) FROM bigtable
>> Internally a GUC setting already exists for a single use, via
>> GUC_ACTION_SAVE, so we just need to invoke it.

> This doesn't read well to me.  It indicates to me "make this setting for
> this query [in case I run it later]", but it does not indicate that the
> query will be run.

Robert's original LET ... IN ... syntax proposal might be better from that
standpoint.

From my perspective Robert's proposal is not targeted to PLpgSQL well, because it doesn't allow to choose granularity.

I am not sure what is result from this discussion:

1. this feature is wanted

2. a opened question is the syntax

I am sure so GUC are not a good design solution for PL/pgSQL. Robert's proposal does thing  bit better, but it has sense more for another environments than PLpgSQL - more, it allows more degree of freedom what has sense for PLpgSQL.

There is possibility to introduce new compile option #option to disable plan cache on function scope. Do you think so it is acceptable solution? It is step forward.

Regards

Pavel



                        regards, tom lane

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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace