Andrew Sullivan <andrew@libertyrms.info> writes:
> On a test machine today, we found simple selects on a table
> with only a couple hundred rows are taking > 300 milliseconds when we
> set the shared buffers to some large number (like enough to allocate
> a Gig of memory), more than 250 ms when running with about 512 Meg of
> shared memory, but under 125 ms when running with a small shared
> buffer setting (say, enough to allocate less than 200 meg -- one test
> we allocated only 4 meg). The main culprit seems to be a memset()
> call that happens over and over to the same address. I've no idea
> why, but there it is.
Hmph. There are some places in the bufmgr that do sequential scans of
the whole buffer array, which might account for a slowdown with huge
numbers of buffers. I do not think any of them are in hotspot paths
however --- at least not in any recent release. This test was on
7.1.something, wasn't it?
Could you recompile with profiling enabled and see where the time is
really going with the large number of buffers?
> The same results are _not_ found in testing with 7.2.1.
This might mean we already fixed the bottleneck, in which case the
question becomes less interesting (at least to me ;-)).
regards, tom lane
