Re: 7.3.1 New install, large queries are slow

On Fri, Jan 17, 2003 at 12:33:11PM -0500, 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
> the kernel to manage a huge number of buffers efficiently more than I
> trust Postgres.

For what it's worth, we have exactly that experience on our Sun
E4500s. I had machines with 12 gig I was testing on, and I increased
the buffers to 2 Gig, because truss was showing us some sluggishness
in the system was tripping on the system call to get a page. It was
satisifed right away by the kernel's cache, but the system call was
still the most expensive part of the operation.

After we'd increased the shared buffers, however, performance
_degraded_ considerably. It now spent all its time instead managing
the huge shared buffer, and the cost of that was much worse than the
cost of the system call.

So it is extremely dependent on the efficiency of PostgreSQL's use of
shared memory as compared to the efficiency of the system call.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110