Re: LWLock contention: I think I understand the problem
От | Hannu Krosing |
---|---|
Тема | Re: LWLock contention: I think I understand the problem |
Дата | |
Msg-id | 3C3595E7.B454CB0@tm.ee обсуждение исходный текст |
Ответ на | Re: LWLock contention: I think I understand the problem (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 по дате отправления: