From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic options for explain |
Date: | 2009-05-24 11:43:51 |
Message-ID: | 4A1932F7.2060905@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Robert,
On 05/24/2009 02:47 AM, Robert Haas wrote:
> Well, here we are! Yet another thread about some piece of information
> that's omitted from EXPLAIN and can't easily be added because there
> are a zillion things we want to add to EXPLAIN and it's not OK to bury
> the user[1]! I've long been of the opinion that the right way to fix
> this problem is to extend the syntax with some sort of extensible
> options syntax[2]. The current "EXPLAIN [ANALYZE] [VERBOSE]<query>"
> syntax does not scale to large numbers of options - it requires that
> the options occur in a fixed order, and that the option names all be
> keywords. Having gotten throughly fed up with having this
> conversation for the ump-teenth time, I wrote a patch to introduce
> just such a syntax. See attached.
> What I did is borrowed the generic options stuff that Peter Eisentraut
> introduced for FOREIGN DATA WRAPPER et. al, so you can write:
> EXPLAIN (option_name1 "option_value1", option_name2 "option_value2") query
> e.g. EXPLAIN (ANALYZE "on") query
Beeing the latest cause for the frustration leading to this patch I
obviously would like something like that - and I would gladly implement
some additional stats suggested by others(if implementable in a
reasonable timeframe) if this approach is agreed uppon.
> - I noticed that we currently acce pt as a top-level SQL command an
> arbitrarily parenthesized SELECT statement, like ((SELECT 3)). But
> you can't put parentheses around any other type of statement. Even
> more oddly, we also accept things like (SELECT 3) ORDER BY 1, which to
> me makes no sense at all.
I would guess that stems from supporting syntax like:
(SELECT 1)
UNION
(SELECT 2)
ORDER BY
and not wanting to introduce a special path for
(SELECT 1)
ORDER BY
For additional stats to be kept another discussion about appropriate,
extensible representation suitable for different output formats probably
would be needed - but thats a discussion for another day.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-05-24 12:44:58 | Re: generic options for explain |
Previous Message | Gevik Babakhani | 2009-05-24 09:32:37 | Re: information_schema.columns changes needed for OLEDB |