Re: MIT benchmarks pgsql multicore (up to 48)performance

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Hakan Kocaman <hkocam(at)googlemail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MIT benchmarks pgsql multicore (up to 48)performance
Date: 2010-10-04 19:22:32
Message-ID: A28AB36A-BA44-45FF-BC05-B8591B71827B@csail.mit.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Oct 4, 2010, at 11:06, Greg Stark <gsstark(at)mit(dot)edu> wrote:

> I guess by "lock-free in the uncontended case" they mean the buffer
> cache manager is lock-free unless you're actually contending on the
> same buffer?

That refers to being able to acquire non-conflicting row/table locks without needing an exclusive LWLock, and acquiring shared LWLocks without spinlocks if possible.

I think the buffer cache manager is the next bottleneck after the row/table lock manager. Seems like it would also be a good candidate for similar techniques, but that's totally uninformed speculation on my part.

Dan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Christensen 2010-10-04 19:25:19 Re: standby registration (was: is sync rep stalled?)
Previous Message Dean Rasheed 2010-10-04 19:20:28 Re: wip: functions median and percentile

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2010-10-04 19:35:44 Re: [PERFORM] MIT benchmarks pgsql multicore (up to 48)performance
Previous Message Josh Berkus 2010-10-04 18:49:43 Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance