Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A00B1133616B for ; Wed, 6 Oct 2010 23:07:15 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 70614-04 for ; Thu, 7 Oct 2010 02:07:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from tamriel.snowman.net (tamriel.snowman.net [72.66.115.51]) by mail.postgresql.org (Postfix) with ESMTP id 318F91336DB6 for ; Wed, 6 Oct 2010 23:07:08 -0300 (ADT) Received: by tamriel.snowman.net (Postfix, from userid 1000) id CAD902228A; Wed, 6 Oct 2010 22:07:07 -0400 (EDT) Date: Wed, 6 Oct 2010 22:07:07 -0400 From: Stephen Frost To: Robert Haas Cc: Ivan Voras , pgsql-performance@postgresql.org Subject: Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance Message-ID: <20101007020707.GP26232@tamriel.snowman.net> References: <20101004175545.GA2690@csail.mit.edu> <4CAA21C7.1030701@agliodbs.com> <20101007013012.GN26232@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Ta7aTnt0awFX15n" Content-Disposition: inline In-Reply-To: X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.26-1-amd64 (x86_64) X-Uptime: 22:02:07 up 405 days, 13:27, 14 users, load average: 0.04, 0.05, 0.00 User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/49 X-Sequence-Number: 40468 --/Ta7aTnt0awFX15n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Robert Haas (robertmhaas@gmail.com) wrote: > It's good to be you. They're HP BL465 G7's w/ 2x 12-core AMD processors and 48G of RAM. Unfortunately, they currently only have local storage, but it seems unlikely that would be an issue for this. > I don't suppose you could try to replicate the lseek() contention? I can give it a shot, but the impression I had from the paper is that the lseek() contention wouldn't be seen without the changes to the lock manager...? Or did I misunderstand? Thanks, Stephen --/Ta7aTnt0awFX15n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkytK0sACgkQrzgMPqB3kijrQQCfUPfNz/RJg/jANoY2lWhR3a3P 2MoAnRteuzESTyJC7XcsTPL8n/1Hskc0 =d5Hp -----END PGP SIGNATURE----- --/Ta7aTnt0awFX15n--