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

Search Discussions

  • Tom Lane at Nov 18, 2010 at 4:27 pm

    Marko Tiikkaja 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
  • Marko Tiikkaja at Nov 18, 2010 at 4:37 pm

    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
  • Andres Freund at Nov 18, 2010 at 4:44 pm

    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
  • Marko Tiikkaja at Nov 18, 2010 at 4:48 pm

    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
  • Andres Freund at Nov 18, 2010 at 4:52 pm

    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
  • Robert Haas at Nov 18, 2010 at 5:26 pm

    On Thu, Nov 18, 2010 at 10:45 AM, 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:
    I have wished for this many, MANY times.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Marko Tiikkaja at Jan 15, 2011 at 8:37 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 18, '10 at 3:45p
activeJan 15, '11 at 8:37p
posts8
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase