Skip site navigation (1) Skip section navigation (2)

Re: 7.3.1 New install, large queries are slow

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: 7.3.1 New install, large queries are slow
Date: 2003-01-17 17:59:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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.


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

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2003-01-17 18:01:09
Subject: Re: 7.3.1 New install, large queries are slow
Previous:From: Bruce MomjianDate: 2003-01-17 17:52:21
Subject: Re: 7.3.1 New install, large queries are slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group