Re: why does count take so long?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: why does count take so long?
Date: 2003-09-08 18:32:54
Message-ID: 87smn75dwp.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Yeah, but I think he's complaining about the 10sec delta for the
> aggregate on top of the 71sec to read the 8 million rows. That
> seems high to me too. On a 10-mil-row test table, I get
...
> in other words 26sec to do the aggregate on top of 163sec to read the
> rows.
>
> Unless Joseph's machine has a way better IO-to-CPU ratio than my little
> development machine, there's something odd about his numbers.

Why is 10s (a 14% delta) for 8M records suspicious but 26s (16% delta) for 10M
not suspicious? These results seem fairly consistent actually.

I think what the original question was is "what work does this 10s represent".
I'm curious too. Is it really just 10 million times the cpu cycles necessary
to dispatch a call to the count() aggregate state function?

PS:

> regression=# explain analyze select count(*) from foo;
> QUERY PLAN
> ------------------------------------------------------------------------------------------------------------------
> Aggregate (cost=22.50..22.50 rows=1 width=0) (actual time=189865.81..189865.81 rows=1 loops=1)
> -> Seq Scan on foo (cost=0.00..20.00 rows=1000 width=0) (actual time=18.88..163833.61 rows=10240000 loops=1)
> Total runtime: 189865.91 msec
> (3 rows)

Hey, you haven't analyzed your table! :)

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Mayer 2003-09-08 18:59:50 Re: ISO 8601 "Time Intervals" of the "format with time-unit deignators"
Previous Message Kaarel 2003-09-08 18:30:40 Re: About GPL and proprietary software