Guillaume
1G is really not a significant amount of memory these days,
That said 6-10% of available memory should be given to an 8.0 or
older version of postgresql
Newer versions work better around 25%
I'm not sure what you mean by mechanically removed from effective_cache
effective cache is really a representation of shared buffers plus OS
cache
Dave
On 1-Sep-06, at 1:00 PM, Guillaume Cottenceau wrote:
Hi,
I've been looking at the results from the pg_statio* tables, to
view the impact of increasing the shared buffers to increase
performance.
As expected, increasing from the default by a factor of 10~20
moves table/index disk blocks reads to cache hits, but the
overall service time of my test page is not changed (I'm testing
with a set of queries implying an increase of 170,000 of
sum(heap_blks_hit) and 2,000 of sum(idx_blks_hit) from
pg_statio_user_tables).
I've seen that documentation says:
data that is not in the PostgreSQL buffer cache may still
reside in the kernel's I/O cache, and may therefore still be
fetched without requiring a physical read
I guess this is the best explanation (btw, my test machine runs
Linux 2.6 on 1G of RAM), but I'm still wondering what should be
expected from moving caching from OS filesystem to PG - probably
PG can "cleverly" flush its cache when it is full (e.g. table
data before index data maybe?), whereas the OS will do it
"blindly", but I'm wondering about the limits of this behaviour,
particularly considering that being "very clever" about cache
flush would probably need realtime query statistics which I am
not sure PG does.
After all, memory added to shared buffers should be mecanically
removed from effective cache size (or others), so I cannot just
increase it until the OS cannot cache anymore :)
--
Guillaume Cottenceau
---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
