Re: REVIEW: EXPLAIN and nfiltered - Mailing list pgsql-hackers

From Tom Lane
Subject Re: REVIEW: EXPLAIN and nfiltered
Date
Msg-id 17474.1295715351@sss.pgh.pa.us
Whole thread Raw
In response to Re: REVIEW: EXPLAIN and nfiltered  (Hitoshi Harada <umi.tanuki@gmail.com>)
Responses Re: REVIEW: EXPLAIN and nfiltered  (David Fetter <david@fetter.org>)
Re: REVIEW: EXPLAIN and nfiltered  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 2011/1/21 Florian Pflug <fgp@phlo.org>:
>> "Rows Skipped: nnn", maybe?

> +1. Very straightforward to me.

I didn't really care for that one, because I think it *won't* be
straightforward when there's more than one filter condition at a node.
Imagine
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Skipped: 42    Filter Cond: blah blah blah    Rows Skipped: 77

To me, "rows skipped" sounds like a statement about the overall behavior
of the plan node, and thus the above looks contradictory.  Another point
is that even if you're okay with the above for textual output, we do not
have a choice about choosing distinct field names for the two counts for
XML/JSON output.

Reflecting on that, I'm inclined to suggest
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Removed by Recheck: 42    Filter Cond: blah blah blah    Rows
Removedby Filter: 77
 

or even more verbosely
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Removed by Recheck Cond: 42    Filter Cond: blah blah blah
RowsRemoved by Filter Cond: 77
 

ie repeat the label of the filtering condition exactly.  This is looking
pretty long, but from the viewpoint of vertical or horizontal space
occupied by the printout, I doubt it matters.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.