The world rejoiced as [EMAIL PROTECTED] (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." ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
