Tom Lane wrote: > NikhilS <[EMAIL PROTECTED]> writes: >> What is the opinion of the list as to the best way of measuring if the >> following implementation is ok? >> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php >> As mentioned in earlier mails, this will reduce the per-backend usage of >> memory by an amount which will be a fraction (single digit percentage) >> of (NBuffers >> * int) size. I have done pgbench/dbt2 runs and I do not see any negative >> impact because of this. > > I find it extremely telling that you don't claim to have seen any > positive impact either. > > I think that the original argument > http://archives.postgresql.org/pgsql-hackers/2006-11/msg00797.php > is basically bogus. At 500000 buffers (4GB in shared memory) the > per-backend space for PrivateRefCount is still only 2MB, which is > simply not as significant as Simon claims; a backend needs at least > that much for catalog caches etc. There is, furthermore, no evidence > that running shared_buffers that high is a good idea in the first > place, or that there aren't other performance bottlenecks that will > manifest before this one becomes interesting.
hmm - we are continuily running into people with dedicated servers that have 16GB RAM or even more available and most tuning docs recommend some 20-30% of system RAM to get dedicated to shared_buffers. So having some 500k buffers allocated does not sound so unrealistic in practise and combined with the fact that people often have a few hundred backends that could add up to some noticable overhead. If that is actually a problem given that those people tend to have heaps of memory is another story but if we can preserve some memory ... Stefan ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
