Re: COUNT and Performance ...

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: hs(at)cybertec(dot)at, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COUNT and Performance ...
Date: 2003-02-02 20:31:59
Message-ID: 1044217919.25210.13.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2003-02-02 at 13:04, Tom Lane wrote:
> I think your test case is small enough that the whole table is resident
> in memory, so this measurement only accounts for CPU time per tuple and
> not any I/O. Given the small size of pgstattuple's per-tuple loop, the
> speed differential is not too surprising --- but it won't scale up to
> larger tables.

Good observation.

When the entire table is in cache, pgstattuple about 4 times faster than
count(*) on my machine. When the table is too large to fit into cache,
the performance difference drops to 8% in favour of pgstattuple:

nconway=# select count(*) from big_table;
count
---------
8388612
(1 row)

Time: 26769.99 ms
nconway=# SELECT tuple_count FROM pgstattuple('big_table');
tuple_count
-------------
8388612
(1 row)

Time: 24658.87 ms

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-02 20:36:01 Re: [PERFORM] not using index for select min(...)
Previous Message Neil Conway 2003-02-02 20:28:15 Re: Last call for 7.3.2