On Tue, 2005-10-11 at 16:54 +0200, Claus Guttesen wrote: > > > I have a postgresql 7.4.8-server with 4 GB ram. > > > #effective_cache_size = 1000 # typically 8KB each > > > > > > This is computed by sysctl -n vfs.hibufspace / 8192 (on FreeBSD). So I > > > changed it to: > > > > > > effective_cache_size = 27462 # typically 8KB each > > > > Apparently this formula is no longer relevant on the FreeBSD systems as > > it can cache up to almost all the available RAM. With 4GB of RAM, one > > could specify most of the RAM as being available for caching, assuming > > that nothing but PostgreSQL runs on the server -- certainly 1/2 the RAM > > would be a reasonable value to tell the planner. > > > > (This was verified by using dd: > > dd if=/dev/zero of=/usr/local/pgsql/iotest bs=128k count=16384 to create > > a 2G file then > > dd if=/usr/local/pgsql/iotest of=/dev/null > > > > If you run systat -vmstat 2 you will see 0% diskaccess during the read > > of the 2G file indicating that it has, in fact, been cached) > > Thank you for your reply. Does this apply to FreeBSD 5.4 or 6.0 on > amd64 (or both)? >
Not sure about 6.0 (but I don't know why it would change) but definitely on 5.4 amd64 (and I would imagine i386 as well). Sven ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match