Re: generic options for explain

On May 26, 2009, at 8:46 AM, Greg Stark <greg(dot)stark(at)enterprisedb(dot)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(at)gmx(dot)net> wrote:
>
>> On Monday 25 May 2009 18:02:53 Tom Lane wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers