Re: Default gucs for EXPLAIN

Поиск
Список
Период
Сортировка
От Vik Fearing
Тема Re: Default gucs for EXPLAIN
Дата
Msg-id b5ca37bd-5205-9f09-f4cc-bff5b6477efb@postgresfriends.org
обсуждение исходный текст
Ответ на Re: Default gucs for EXPLAIN  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Default gucs for EXPLAIN  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 5/27/20 7:27 AM, David G. Johnston wrote:
> On Tuesday, May 26, 2020, David Rowley <dgrowleyml@gmail.com> wrote:
> 
>> On Tue, 26 May 2020 at 23:59, Vik Fearing <vik@postgresfriends.org> wrote:
>>> Are you saying we should have all new EXPLAIN options off forever into
>>> the future because apps won't know about the new data?  I guess we
>>> should also not ever introduce new plan nodes because those won't be
>>> known either.
>>
>> Another argument against this is that it creates dependency among the
>> new GUCs. Many of the options are not compatible with each other. e.g.
>>
>> postgres=# explain (timing on) select 1;
>> ERROR:  EXPLAIN option TIMING requires ANALYZE
>>
>> Would you propose we just error out in that case, or should we
>> silently enable the required option, or disable the conflicting
>> option?
>>
>>
> The same thing we do today...ignore options that require analyze if analyze
> is not specified.  There are no other options documented that are dependent
> with options besides than analyze.  The docs say timing defaults to on, its
> only when explicitly specified instead of being treated as a default that
> the user message appears.  All the GUCs are doing is changing the default.


Yes, the patch handles this case the way you describe.  In fact, the
patch doesn't (or shouldn't) change any behavior at all.
-- 
Vik Fearing



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Trouble with hashagg spill I/O pattern and costing
Следующее
От: Amit Khandekar
Дата:
Сообщение: Re: Inlining of couple of functions in pl_exec.c improves performance