Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD

> Anyway, the original writer didn't specify an architechure. If it is a
> 32bit one it is entirly possible that the memory map simply has no
> large contiguous space to map the shared memory.

it's 32bit. The actual problem of giving more buffers to postgresql
was solved with the help of the following post:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=83003+0+archive/2002/freebsd-hackers/20020804.freebsd-hackers

It looks like despite to the comment in /usr/src/sys/i386/include/vmparam.h

#ifndef MAXDSIZ
#define MAXDSIZ (512UL*1024*1024) /* max data size */
#endif

for FreeBSD MAXDSIZ actually tells kernel where to start allocating
memory, but not the maximum allowable size. Cause as soon as I lowered
this value from 2500UL*1024*1024(what I set when I was setting up the
server) to 1024UL*1024*1025, I was able to further increase shared
buffers in postgres.conf.

Also, while I can agree with the point that "maybe OS file caching
algorythm is more efficient than PostgreSQL's", but that still doest
give us single meaning answer because:
1) for PostgreSQL the job of fetching the data from OS buffers should
imply some overhead compared to accessing the data cached in shared
buffers.
2) there is no guarantee that OS dedicates all the rest of available
RAM for file caching. In fact, in case there are other processes
running on the server, perhaps I want to make sure that that much
memory is dedicated solely for PostgreSQL data caching, and the only
way for that is increasing shared buffers.

later today I will do some performance testing with shared buffers set
to 50k as Tom suggested and then with, lets say 200k and post the
results here.

--
Vlad