| 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: | Whole Thread | Raw Message | 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 |