From: | Fabian Kreitner <fabian(dot)kreitner(at)ainea-ag(dot)de> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Force table to be permanently in cache? |
Date: | 2003-08-29 12:52:10 |
Message-ID: | 5.1.0.14.0.20030829144416.03be0248@195.145.148.245 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-08-29 12:56:19 | Re: ALTER TABLE |
Previous Message | Ron Johnson | 2003-08-29 12:05:36 | Re: Hardware recommendations to scale to silly load |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2003-08-29 12:52:34 | Re: bad estimates |
Previous Message | Ron Johnson | 2003-08-29 12:05:36 | Re: Hardware recommendations to scale to silly load |