Re: generic options for explain
От | Robert Haas |
---|---|
Тема | Re: generic options for explain |
Дата | |
Msg-id | F05A8297-10BC-4262-ADCC-E66BF1B9CE3B@gmail.com обсуждение исходный текст |
Ответ на | Re: generic options for explain (Greg Stark <greg.stark@enterprisedb.com>) |
Список | pgsql-hackers |
On May 26, 2009, at 8:46 AM, Greg Stark <greg.stark@enterprisedb.com> wrote: > Well I want an SQL query-able format. I also want a way to retrieve > the data for a query run from within an application without > disturbing the application i.e. while still returning the regular > result set. > > But I also like being able to conveniently run explain and get the > results formatted to fit on the screen in a single step. I don't see > anything wrong with Robert's direction to pass options to explain. > It doesn't solve every problem but it doesn't make any of the other > things we need harder either. Your check is in the mail, too. > On a bike-shedding note I would rather have the rhs of the option be > optional and default to true for boolean options. I was thinking about that, too, so +1. > Actually if we make a set of explain_* guc options we could make the > options just locally set those options. I think that's probably over-complicated, but that's just MHO. ...Robert > > > -- > Greg > > > On 26 May 2009, at 13:15, Peter Eisentraut <peter_e@gmx.net> wrote: > >> On Monday 25 May 2009 18:02:53 Tom Lane wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> This is all much more complicated than what I proposed, and I >>>> fail to >>>> see what it buys us. I'd say that you're just reinforcing the >>>> point I >>>> made upthread, which is that insisting that XML is the only way >>>> to get >>>> more detailed information will just create a cottage industry of >>>> beating that XML output format into submission. >>> >>> The impression I have is that (to misquote Churchill) XML is the >>> worst >>> option available, except for all the others. We need something >>> that can >>> represent a fairly complex data structure, easily supports >>> addition or >>> removal of particular fields in the structure (including fields not >>> foreseen in the original design), is not hard for programs to parse, >>> and is widely supported --- ie, "not hard" includes "you don't >>> have to >>> write your own parser, in most languages". How many realistic >>> alternatives are there? >> >> I think we are going in the wrong direction. No one has said that >> they want a >> machine-readable EXPLAIN format. OK, there are historically about >> three >> people that want one, but they have already solved the problem of >> parsing the >> current format. And without having writtens such a parser myself I >> think that >> the current format is not inherently hard to parse. >> >> What people really want is optional additional information in the >> human- >> readable format. Giving them a machine readable format does not >> solve the >> problem. Giving them a machine readable format with all-or-none of >> the >> optional information and saying "figure it out yourself" does not >> solve >> anything either. The same people who currently complain will >> continue to >> complain. >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления:
Следующее
От: Greg StarkДата:
Сообщение: Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)