[PERFORM] Force table to be permanently in cache?
Hi everyone, I have a sql request which on first invocation completes in ~12sec but then drops to ~3sec on the following runs. The 3 seconds would be acceptable but how can I make sure that the data is cached and all times? Is it simply enough to set shared_buffers high enough to hold the entire database (and have enough ram installed of course)? The OS is linux in this case. Nested Loop (cost=0.00..11.44 rows=1 width=362) (actual time=247.83..12643.96 rows=14700 loops=1) - Index Scan using suchec_testa on suchec (cost=0.00..6.02 rows=1 width=23) (actual time=69.91..902.68 rows=42223 loops=1) - Index Scan using idx_dokument on dokument d (cost=0.00..5.41 rows=1 width=339) (actual time=0.26..0.26 rows=0 loops=42223) Total runtime: 12662.64 msec Nested Loop (cost=0.00..11.44 rows=1 width=362) (actual time=1.18..2829.79 rows=14700 loops=1) - Index Scan using suchec_testa on suchec (cost=0.00..6.02 rows=1 width=23) (actual time=0.51..661.75 rows=42223 loops=1) - Index Scan using idx_dokument on dokument d (cost=0.00..5.41 rows=1 width=339) (actual time=0.04..0.04 rows=0 loops=42223) Total runtime: 2846.63 msec ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Force table to be permanently in cache?
On Fri, Aug 29, 2003 at 02:52:10PM +0200, Fabian Kreitner wrote: Hi everyone, I have a sql request which on first invocation completes in ~12sec but then drops to ~3sec on the following runs. The 3 seconds would be acceptable but how can I make sure that the data is cached and all times? Is it simply enough to set shared_buffers high enough to hold the entire database (and have enough ram installed of course)? The OS is linux in this case. If the table gets hit often enough, then it'll be in your filesystem cache anyway. See the many discussions of sizing shared_buffers in the archives of this list for thoughts on how big that should be. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(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
