On Thu, Jul 07, 2005 at 06:23:40PM +0200, Hans-Jürgen Schönig wrote:
> Tom Lane wrote:
> >Koichi Suzuki <[EMAIL PROTECTED]> writes:
> >>Here're a couple of patches for PostgreSQL 64bit support. There're just
> >>two extension to 64bit, size of shared memory and transaction ID.
> >I asked originally for some experimental evidence showing any value
> >in having more than 2Gb of shared buffers. In the absence of any
> >convincing demonstration, I'm not very inclined to worry about whether
> >we can handle wider-than-int shared memory size.
> There is some practical evidence. Recently the number of large boxes in
> the field is almost growing exponentially. Today I have heard somebody
> say "this box has 'just 4 gig of ram' ".
Yes, but the point is if it's a good idea to have that many shared
buffers. Is there a measurable difference between that, and leaving the
extra memory for the kernel to manage cache? Remember that there have
been measurements that showed, for previous releases, that having shared
buffers set too high was detrimental to performance. So the first thing
to do is present results showing that this is no longer true.
This could very well be the case, because of the rewriting of the buffer
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"El destino baraja y nosotros jugamos" (A. Schopenhauer)
---------------------------(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