Re: LWLock contention: I think I understand the problem - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: LWLock contention: I think I understand the problem
Date
Msg-id 3C3595E7.B454CB0@tm.ee
Whole thread Raw
In response to Re: LWLock contention: I think I understand the problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 
> Hannu Krosing <hannu@tm.ee> writes:
> > Tom Lane wrote:
> >> Unfortunately, at low scaling factors pgbench is guaranteed to look
> >> horrible because of contention for the "branches" rows.
> >>
> > Not really! See graph in my previous post - the database size affects
> > performance much more !
> 
> But the way that pgbench is currently set up, you can't really tell the
> difference between database size effects and contention effects, because
> you can't vary one while holding the other constant.

What I meant was that a small -s (lot of contention and small database) 
runs much faster than  tham big -s (low contention and big database)

> I based my comments on having done profiles that show most of the CPU
> time going into attempts to acquire row locks for updates and/or
> checking of dead tuples in _bt_check_unique.  So at least in the
> conditions I was using (single CPU) I think those are the bottlenecks.
> I don't have any profiles for SMP machines, yet.

You have good theoretical grounds for your claim - it just does not fit 
with real-world tests. It may be due to contention in some other places 
but not on the branches table (i.e small scale factor)

--------------
Hannu



pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: datetime error?
Next
From: Palle Girgensohn
Date:
Subject: Re: Is there any performance penalty using --with-ssl?