Re: Performance of count(*)

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: "Andreas Tille" <tillea(at)rki(dot)de>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance of count(*)
Date: 2007-03-22 14:46:26
Message-ID: C227E4D2.2A1D3%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Andreas,

On 3/22/07 4:48 AM, "Andreas Tille" <tillea(at)rki(dot)de> wrote:

> Well, to be honest I'm not really interested in the performance of
> count(*). I was just discussing general performance issues on the
> phone line and when my colleague asked me about the size of the
> database he just wonderd why this takes so long for a job his
> MS-SQL server is much faster. So in principle I was just asking
> a first question that is easy to ask. Perhaps I come up with
> more difficult optimisation questions.

This may be the clue you needed - in Postgres SELECT COUNT(*) is an
approximate way to measure the speed of your disk setup (up to about
1,200MB/s). Given that you are having performance problems, it may be that
your disk layout is either:
- slow by design
- malfunctioning

If this is the case, then any of your queries that require a full table scan
will be affected.

You should check your sequential disk performance using the following:

time bash -c "dd if=/dev/zero of=/your_file_system/bigfile bs=8k
count=(your_memory_size_in_KB*2/8) && sync"
time dd if=/your_file_system/bigfile of=/dev/null bs=8k

Report those times here and we can help you with it.

- Luke

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message mark 2007-03-22 14:52:27 Re: Performance of count(*)
Previous Message Michael Stone 2007-03-22 14:41:51 Re: Performance of count(*)