From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Explain output: wrong row count? |
Date: | 2004-11-25 17:46:58 |
Message-ID: | 675.1101404818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I have this EXPLAIN ANALYZE output:
> ...
> -> Hash (cost=13.99..13.99 rows=499 width=89) (actual time=5.947..5.947 rows=0 loops=1)
> -> Seq Scan on ciudad (cost=0.00..13.99 rows=499 width=89) (actual time=0.018..3.909 rows=499 loops=1)
> Note that the Hash step has an estimated row count of 499 (which is a
> good estimate), but the actual row count is 0, which is way off.
The "actual rows" count on a Hash node is always 0, because we don't
retrieve rows from it in the normal way (ie via ExecProcNode). The
actual row count from the child plan node (here, the 499 for the
seqscan) tells you how many rows got loaded into the hashtable.
I've occasionally thought about putting in some kind of kluge to set the
"actual rows" count to the hash table size, just because it looks funny
to have zero there. But it hasn't got to the top of the to-do list ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-11-25 17:51:51 | Re: Solaris 8 regression test failure with 8.0.0beta5 |
Previous Message | Greg Stark | 2004-11-25 17:05:39 | Re: Solaris 8 regression test failure with 8.0.0beta5 |