On Thu, Jan 20, 2011 at 3:47 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
