Andreas, On 3/22/07 4:48 AM, "Andreas Tille" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
