Re: [PATCH] Add EXPLAIN (ALL) shorthand

Поиск
Список
Период
Сортировка
От Pete Hollobon
Тема Re: [PATCH] Add EXPLAIN (ALL) shorthand
Дата
Msg-id CACojYcG3W6iSjjy+ZM-5TV5kfQaBDTP5CgerVK0uY-1tktJuew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Add EXPLAIN (ALL) shorthand  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
<p dir="ltr"><br /> On 21 May 2016 16:07, "David G. Johnston" <<a
href="mailto:david.g.johnston@gmail.com">david.g.johnston@gmail.com</a>>wrote:<br /> > ​And most of the time the
choiceof options is totally arbitrary based upon the mood and experience of the user, so what's it matter if they saved
afew keystrokes and set the GUC in the .psqlrc​ file?<br /> ><br /> >> I'm predicting users that will have<br
/>>> trouble while using EXPLAIN if someone change the suggested GUC. It also<br /> >> breaks
clients/applicationsthat parse EXPLAIN.<br /> ><br /> ><br /> > ​Pretty much the same argument as above.​<br
/>><br /> > I would not expect a DBA to set this value globally - but shame on them if they do.  I'd expect
eitherALTER ROLE or SET usage, in .psqlrc if applicable, to be the dominate usage for setting the value to a non-empty
string. There is UI to consider here but I don't see any fundamental problems.<p dir="ltr">A GUC seems like overkill
forpsql. I have the following in my .psqlrc: <p dir="ltr">\set expall 'EXPLAIN (analyze, buffers, costs, timing,
verbose)'<p dir="ltr">That lets you type<p dir="ltr">:expall select a, b from whatever;<p dir="ltr">For GUI tools like
pgadminyou've often got built in explain tools anyway.<p dir="ltr">> David J.<br /> > 

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Parallel safety tagging of extension functions
Следующее
От: Rushabh Lathia
Дата:
Сообщение: Re: Error during restore - dump taken with pg_dumpall -c option