On Thu, Jan 20, 2011 at 3:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The main functional problem I see with this format is that it assumes
> there is one and only one filter step associated with every plan node.
> That is just plain wrong. Many don't have any, and there are important
> cases where there are two. I'm thinking in particular that it might be
> useful to distinguish the effects of the recheck and the filter
> conditions of a bitmap heap scan.
If it's not too hard to do that, I'm all in favor.
> Maybe it'd also be interesting to
> separate the join and non-join filter clauses of a join node, though
> I'm less sure about the usefulness of that.
That would also be extremely useful.
> So the line I'm thinking we should pursue is to visually associate the
> new counter with the filter condition, either like
>
> Filter Cond: (x > 42) (nfiltered = 123)
>
> or
>
> Filter Cond: (x > 42)
> Rows Filtered: 123
>
> The latter is less ambiguous, but takes more vertical space. The former
> is very unlikely to break any client code, because I doubt there is any
> that inquires into the details of what a filter condition expression
> really means. The latter *might* break code depending on how much
> it assumes about the number of detail lines attached to a plan node
> ... but as Robert pointed out, we've added new detail lines before.
I like the idea of putting it on the same line as the filter
condition, but your proposal for how to do that doesn't wow me - the
parentheses look too similar to the ones around the qual itself.
> BTW, is it just me, or is the terminology "number filtered" pretty
> confusing/ambiguous in itself? It doesn't seem at all clear to me
> whether that's the number of rows passed by the filter condition or
> the number of rows rejected. Perhaps "nremoved" would be clearer.
I think filtered is pretty clear and like it... removed sounds like
you deleted something.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
