From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(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-24 22:53:29 |
Message-ID: | 13099.1243205609@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> 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.
> Something that returns a setof can also be easily used to implement the
> "dump EXPLAIN to a table" feature Josh Tolley brought up (which is another
> common request in this area).
A serious problem with EXPLAIN via a function returning set, or with
putting the result into a table, is that set results are logically
unordered, just as table contents are. So from a strict point of view
this only makes sense when the output format is designed to not depend
on row ordering to convey information. We could certainly invent such
a format, but I think it's a mistake to go in this direction for
EXPLAIN output that is similar to the current output.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-24 23:51:55 | Re: [HACKERS] pull raw text of a message by message-id |
Previous Message | Tom Lane | 2009-05-24 22:46:26 | Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) |