Scott Marlowe writes:
> Yes, effective_cache_size is the postgresql setting that
> tells the postmaster we have "about this much kernel cache"
> on average.
>
> If it's set low, then postgresql assumes the kernel isn't
> caching much, if it's higher, then it assumes it's more
> likely for data to be "in memory"
> and makes index scans more likely than seq scans.
>
> Sorry, I should have pointed out I was talking out about a
> postgresql configuration parameter and not a linux one...
Ahh. Thanks for the tip (I am still new to Pg).
I guess the reason Pg can't ask the running kernel how much cache mem it
has is that any such thing would be completely non-portable.
Now branching the thread:
The documentation (doc/runtime-config.html in my 7.3.2 source tree) says
the value is a number of disk pages, and that disk pages are usualy 8KB.
My filesystem has 4KB blocks; are blocks and pages the same thing in
this context, or does "page" refer to the in-memory copy of a disk
block? Are bigger blocks/pages on the filesystem used for Pg a good
idea? I would guess yes, since Pg's data files are few and large,
instead of many and small. Should I just crank my fs block size as big
as it will go, on a partition dedicated to pg_data?
Thanks.