From: | Greg Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFD: Discarded tuple count for SeqScan nodes in EXPLAIN ANALYZE |
Date: | 2009-05-22 16:11:46 |
Message-ID: | 4136ffa0905220911jec20a34ha1830e2dd67e8643@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 22, 2009 at 4:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> It doesn't really seem useful enough to justify breaking client-side
> code that looks at EXPLAIN output.
Fwiw at least pgadmin I don't think would be confused by this. These
tool authors aren't enamoured of fragile assumptions and the
maintenance headaches they cause either.
> This sort of ties into the discussions we have periodically about
> allowing EXPLAIN to output XML or some other more-machine-friendly
> data format. The barrier for adding additional output fields would
> be a lot lower in such a format.
This is still pretty much true if only for the sheer unscalability of
the amount of data being presented for users to sift through. I do
want us to add a ton more instrumentation into the explain plan and
this is only one small addition. If we add number of hard and soft
i/os, time spent in user and system space, etc the result would be
pretty unreadable and they're at least as important as things like
this.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-05-22 16:27:33 | Revisiting default_statistics_target |
Previous Message | Greg Stark | 2009-05-22 15:59:03 | Re: Common Table Expressions applied; some issues remain |