From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Raney <twraney(at)comcast(dot)net> |
Cc: | David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic options for explain |
Date: | 2009-05-25 20:53:12 |
Message-ID: | 4A1B0538.20001@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Tom,
On 05/25/2009 08:04 PM, Tom Raney wrote:
> So, why not put ALL interesting data in the EXPLAIN XML feed? I'm not
> suggesting for this discussion that we include discarded plans, but that
> we include every piece of data that may be of interest to folks building
> connecting tools. The parsers can pick and choose what they use easily
> and, because the feed isn't positional, won't break when addition data
> is added. A GUC parameter could govern the data included in this variant
> of EXPLAIN, but even that seems unnecessary. This approach will allow
> the standard EXPLAIN to evolve in whatever way pleases the humans
> without interfering with the machines.
Well, there is the problem Robert Haas described - some stats may be too
expensive to gather (like the io-stats) for regular use, but still be
quite usefull.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-05-25 22:12:13 | Re: generic options for explain |
Previous Message | Tom Lane | 2009-05-25 19:41:10 | Re: No sanity checking performed on binary TIME parameters. |