"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> writes:
> On 17 Jan 2003 at 12:33, Tom Lane wrote:
>> One reason not to crank up shared_buffers "just because you can" is that
>> there are operations (such as CHECKPOINT) that have to scan through all
>> the buffers, linearly. I don't *think* any of these are in
>> performance-critical paths, but nonetheless you're wasting CPU. I trust
> Assuming that one knows what he/she is doing, would it help in such cases i.e.
> the linear search thing, to bump up page size to day 16K/32K?
You mean increase page size and decrease the number of buffers
proportionately? It'd save on buffer-management overhead, but
I wouldn't assume there'd be an overall performance gain. The
system would have to do more I/O per page read or written; which
might be a wash for sequential scans, but I bet it would hurt for
random access.
> and that is also the only way to make postgresql use more than couple of gigs
> of RAM, isn't it?
It seems quite unrelated. The size of our shared memory segment is
limited by INT_MAX --- chopping it up differently won't change that.
In any case, I think worrying because you can't push shared buffers
above two gigs is completely wrongheaded, for the reasons already
discussed in this thread. The notion that Postgres can't use more
than two gig because its shared memory is limited to that is
*definitely* wrongheaded. We can exploit however much memory your
kernel can manage for kernel disk cache.
regards, tom lane