This is the second time I've heard that "PG shared buffer on Windows doesn't matter" ... I'd like to understand the reasoning behind that claim, and why it differs from other DB servers.
.... though that's much less important for Pg than for most other things, as Pg uses a one-process-per-connection model and lets the OS handle much of the caching. So long as the OS can use all that RAM for caching, Pg will benefit, and it's unlikely you need >2GB for any given client connection or for the postmaster.
Any DB software would benefit from the OS buffer cache, but there is still the overhead of copying that data into the shared buffer area, and as necessary unpacking it into in-memory format.
Oracle uses a more or less identical process and memory model to PG, and for sure you can't have too much SGA with it.
It's nice to have the flexibility to push up shared_buffers, and it'd be good to avoid any overheads in running 32-bit code on win64. However, it's not that unreasonable to run a 32-bit Pg on a 64-bit OS and expect good performance.
My reasoning goes like this:
a. there is a significant performance benefit to using a large proportion of memory as in-process DB server cache instead of OS level block / filesystem cache
b. the only way to do so on modern hardware (i.e. >>4GB) is with a 64-bit binary
c. therefore, a 64-bit binary is essential
You're the second person that's said a. is only a "nice to have" with PG ... what makes the difference?
Cheers
Dave