From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic options for explain |
Date: | 2009-05-25 01:29:36 |
Message-ID: | 603c8f070905241829k578a5f60uf4c6f4dad706bd42@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 24, 2009 at 6:05 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> On Sun, 24 May 2009, Pavel Stehule wrote:
>
>> we should have a secondary function explain_query(query_string,
>> option) that returns setof some.
>
> +1. The incremental approach here should first be adding functions that
> actually do the work required. Then, if there's a set of those that look to
> be extremely useful, maybe at that point it's worth talking about how to
> integrate them into the parser. Starting with the parser changes rather
> than the parts that actually do the work is backwards. If you do it the
> other way around, at all times you have a patch that actually provides
> immediate useful value were it to be committed.
Well, perhaps I ought to be asking what sort of features people would
like to see, other than variant output formats? Maybe if we can
develop some kind of wish list for EXPLAIN, it will become more
obvious what the best option syntax is.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-05-25 03:06:36 | Re: generic options for explain |
Previous Message | Robert Haas | 2009-05-25 01:27:01 | Re: generic options for explain |