Обсуждение: EXPLAIN and nfiltered

Hi,

Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input.  The output looks like this:


                                                       QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
  Subquery Scan on ss  (cost=0.00..50.00 rows=267 width=4) (actual
time=0.035..0.088 rows=5 filtered=3 loops=1)
    Filter: (ss.a < 6)
    ->  Limit  (cost=0.00..40.00 rows=800 width=4) (actual
time=0.031..0.067 rows=8 filtered=0 loops=1)
          ->  Seq Scan on foo  (cost=0.00..40.00 rows=800 width=4)
(actual time=0.027..0.040 rows=8 filtered=2 loops=1)
                Filter: (a < 9)
  Total runtime: 0.146 ms
(6 rows)


It might be better if the output was on the Filter: line but this was
just the result of a quick idea and I wanted to see how much work the
actual implementation would be.

Any suggestions and comments on the output format, the patch and the
idea are welcome.


Regards,
Marko Tiikkaja

Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan 
> qual filtered from a node's input.

I don't like this a whole lot.  It's unclear what "filtered" means,
or why it's worth expending precious EXPLAIN ANALYZE output space for.

Also, you've not implemented it for any except scan nodes; and I
think it's not going to be entirely well-defined for join nodes,
since it's somewhat arbitrary which conditions are considered part
of the join qual versus the filter.  (That problem will get worse
not better with the planned generalization of inner indexscans,
since there may be join quals in scan nodes.)
        regards, tom lane

On 2010-11-18 6:26 PM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi>  writes:
>> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
>> qual filtered from a node's input.
>
> I don't like this a whole lot.  It's unclear what "filtered" means,
> or why it's worth expending precious EXPLAIN ANALYZE output space for.

The name can be changed, of course.  But I think the idea is good; I 
find myself constantly manually finding out how many rows were actually 
filtered.

> Also, you've not implemented it for any except scan nodes;

That was intentional.

> and I
> think it's not going to be entirely well-defined for join nodes,
> since it's somewhat arbitrary which conditions are considered part
> of the join qual versus the filter.  (That problem will get worse
> not better with the planned generalization of inner indexscans,
> since there may be join quals in scan nodes.)

Hmm..  Maybe I'm misunderstanding something, but I don't see that as a 
huge problem.


Regards,
Marko Tiikkaja

On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> Hi,
> 
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input.  The output looks like this:
If it supports the same for index-scans I *really* like it and even proposed a 
patch earlier (4A16A8AF.2080508@anarazel.de)
I still find myself constantly wishing to have something like that... 
Especially when wondering if it might be worthwile to add another column 
(which is implemented as an additional qual atm) should get included in a 
multiicolumn index.

It was shot down at the time because it might break some explain-parsers 
expectations. Imho that argument is less valid these days.

Andres

On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
> On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
>> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
>> qual filtered from a node's input.  The output looks like this:
> If it supports the same for index-scans I *really* like it and even proposed a
> patch earlier (4A16A8AF.2080508@anarazel.de)
> I still find myself constantly wishing to have something like that...
> Especially when wondering if it might be worthwile to add another column
> (which is implemented as an additional qual atm) should get included in a
> multiicolumn index.
>
> It was shot down at the time because it might break some explain-parsers
> expectations. Imho that argument is less valid these days.

I have to admit, I didn't query the archives before looking at this.  I 
guess I should have.  This patch supports all Scan nodes, and I think 
that's the right thing to do.

I agree 100% that breaking the parseability (is that a word?) of the 
EXPLAIN output is not really an argument these days, so we might want to 
give this some thought.


Regards,
Marko Tiikkaja

On Thursday 18 November 2010 17:48:43 Marko Tiikkaja wrote:
> On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
> > On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> >> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> > 
> >> qual filtered from a node's input.  The output looks like this:
> > If it supports the same for index-scans I *really* like it and even
> > proposed a patch earlier (4A16A8AF.2080508@anarazel.de)
> > I still find myself constantly wishing to have something like that...
> > Especially when wondering if it might be worthwile to add another column
> > (which is implemented as an additional qual atm) should get included in a
> > multiicolumn index.
> > 
> > It was shot down at the time because it might break some explain-parsers
> > expectations. Imho that argument is less valid these days.
> 
> I have to admit, I didn't query the archives before looking at this.  I
> guess I should have.  This patch supports all Scan nodes, and I think
> that's the right thing to do.
Uh. No worries. That was my first pg-patch, I doubt it was well-done ;-)

> I agree 100% that breaking the parseability (is that a word?) of the
> EXPLAIN output is not really an argument these days, so we might want to
> give this some thought.
Yes.

Andres

On Thu, Nov 18, 2010 at 10:45 AM, Marko Tiikkaja
<marko.tiikkaja@cs.helsinki.fi> wrote:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan qual
> filtered from a node's input.  The output looks like this:

I have wished for this many, MANY times.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2010-11-18 5:45 PM +0200, Marko Tiikkaja wrote:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input.

Rebased against master.


Regards,
Marko Tiikkaja