Re: Slow count(*) again...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Whelchel <neil(dot)whelchel(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow count(*) again...
Date: 2010-10-13 13:49:12
Message-ID: 24768.1286977752@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Neil Whelchel <neil(dot)whelchel(at)gmail(dot)com> writes:
> Insert the data into one table:
> crash:~# time psql -U test test -q < log.sql
> real 679m43.678s
> user 1m4.948s
> sys 13m1.893s

> crash:~# echo 3 > /proc/sys/vm/drop_caches
> crash:~# time psql -U test test -c "SELECT count(*) FROM log;"
> count
> ----------
> 10050886
> (1 row)

> real 0m11.812s
> user 0m0.000s
> sys 0m0.004s

> crash:~# time psql -U test test -c "SELECT count(*) FROM log;"
> count
> ----------
> 10050886
> (1 row)

> real 0m3.737s
> user 0m0.000s
> sys 0m0.000s

> As can be seen here, the cache helps..

That's probably got little to do with caching and everything to do with
setting hint bits on the first SELECT pass.

I concur with Mark's question about whether your UPDATE pushed the table
size across the limit of what would fit in RAM.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-10-13 13:51:45 Re: Issues with two-server Synch Rep
Previous Message Kevin Grittner 2010-10-13 13:45:00 Re: Slow count(*) again...

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2010-10-13 13:50:33 Re: SQL functions vs. PL/PgSQL functions
Previous Message Kevin Grittner 2010-10-13 13:45:00 Re: Slow count(*) again...