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
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
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
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2003-09-16 05:19:00|
|Subject: Re: restore time: sort_mem vs. checkpoing_segments |
|Previous:||From: Brian Hirt||Date: 2003-09-16 00:39:53|
|Subject: Re: Inconsistent performance|