Skip site navigation (1) Skip section navigation (2)

Re: Inconsistent performance

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Inconsistent performance
Date: 2003-09-16 02:26:45
Message-ID: m38yoptqmy.fsf@wolfe.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-performance
The world rejoiced as jbove(at)vetstar(dot)com (Joseph Bove) wrote:
> Actually, it's inconsistent with the exact same command. I've now
> replicated the problem by doing the following command:
>
> select count (*) from table;
>
> The table in question has 88899 rows.
>
> The response time is anywhere from 1 second to 12 seconds. Different
> response times can occur in the same minute of testing!

The only possible plan for THAT query will involve a seq scan of the
whole table.  If the postmaster already has the data in cache, it
makes sense for it to run in 1 second.  If it has to read it from
disk, 12 seconds makes a lot of sense.

You might want to increase the "shared_buffers" parameter in
postgresql.conf; that should lead to increased stability of times as
it should be more likely that the data in "table" will remain in
cache.
-- 
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/x.html
Signs of  a  Klingon  Programmer -  8.  "Debugging?   Klingons do  not
debug.  Our software  does not   coddle the  weak. Bugs  are  good for
building character in the user."

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2003-09-16 05:19:00
Subject: Re: restore time: sort_mem vs. checkpoing_segments
Previous:From: Brian HirtDate: 2003-09-16 00:39:53
Subject: Re: Inconsistent performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group