Re: lazy vxid locks, v2

On Fri, Jul 15, 2011 at 4:41 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> (1) can you re-link me to the pgbench and sysbench setup you used to
> test this originally?  I'd like to implement those.

I didn't use sysbench. The pgbench command I used was something like:

pgbench -n -S -T $TIME -c $CLIENTS -j $CLIENTS

...with varying times and client counts. Three minutes or so seems to
be enough to get a reasonably good measurement. We have a report from
another tester that -M prepared exacerbates the effect of the main
fastlock patch (which I just committed) so that might be worth trying
here, too.

> (2) the max machine I can test these on is 16 cores.  Is that adequate,
> or do we need more cores for real testing?

I think you should be able to see a small benefit on a machine of that
size. My memory is a bit fuzzy because it's 1 AM and I haven't looked
at this in over a week, but I believe that this patch produces only a
small improvement in performance by itself, apparently because most of
the gain that we get from reducing lock manager contention gets eaten
up by additional spinlock contention. However, I think the change is
worthwhile anyway, because the benefit of any changes we might make to
reduce spinlock contention is going to be limited by the rate at which
we can shove traffic through the lock manager. In other words, aside
from whatever benefit this patch may have on its own, I believe it's
an enabler for future performance work.

In mulling over this patch, it's occurred to me that there are some
stylistic things about it that can stand to be improved. So I'm going
to do that for the next version. However, if you want to test on this
version, feel free, because I think those changes are going to have
little if any effect on performance.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company