> From: Greg Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 19, 2008 9:03 PM
>
> So, yes, in 8.3 it's possible that you can have sequential
> scans of large
> tables or the VACUUM data pass through the buffer cache, but
> not remain in
> it afterwards. I didn't think George would ever r
On Mon, 19 May 2008, Decibel! wrote:
Hrm... don't seqscans use a separate set of buffers in 8.3? While technically
those won't be evicted until needed, you're unlikely to find stuff hanging
around there for terribly long...
Not quite a separate set, and I have been remiss that I only skim ove
On May 14, 2008, at 6:18 PM, Greg Smith wrote:
Also, how long should pages stay in the cache? (Assuming I have
way more
memory than the total size of all the tables/indexes.) Is there any
time-based expiration (in addition to LRU-based, which in my case
should
never be resorted to)?
Foreve
On Wed, 14 May 2008, George Pavlov wrote:
Is there a way to tell whether a query is satisfied from memory cache or
from disk.
No. You can look at the hit rate statistics for the tables and indexes
referenced and see how they change before and after the query, but this
just tells you about w
I am on PG 8.1.10 on RedHat Linux. Some page cache/query performance
questions:
Is there a way to tell whether a query is satisfied from memory cache or
from disk. The only way I know of is based on the time the query takes
(reported by EXPLAIN ANALYZE) -- comparing the first-time performance
(aft
