Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 756752E0042 for ; Fri, 18 Apr 2008 03:47:26 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 51001-06 for ; Fri, 18 Apr 2008 03:47:23 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from westnet.com (westnet.com [216.187.52.2]) by developer.postgresql.org (Postfix) with ESMTP id E8C3D2E002D for ; Fri, 18 Apr 2008 03:47:23 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m3I6lM0l007226 for ; Fri, 18 Apr 2008 02:47:22 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m3I6lMt4007220 for ; Fri, 18 Apr 2008 02:47:22 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Fri, 18 Apr 2008 02:47:22 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: pgsql-performance@postgresql.org Subject: Re: Strange behavior: pgbench and new Linux kernels In-Reply-To: <22550.1208495934@sss.pgh.pa.us> Message-ID: References: <22550.1208495934@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/263 X-Sequence-Number: 29756 On Fri, 18 Apr 2008, Tom Lane wrote: > Yeah, it's starting to be obvious that we'd better not ignore sysbench > as "not our problem". Do you have any roadmap on what needs to be done > to it? Just dug into this code again for a minute and it goes something like this: 1) Wrap the write statements into transactions properly so the OLTP code works. There's a BEGIN/COMMIT in there, but last time I tried that test it just deadlocked on me (I got a report of the same from someone else as well). There's some FIXME items in the code for PostgreSQL already that might be related here. 2) Make sure the implementation is running statistics correctly (they create a table and index, but there's certainly no ANALYZE in there). 3) Implement the part of the driver wrapper that haven't been done yet. 4) Try to cut down on crashes (I recall a lot of these when I tried to use all the features). 5) Compare performance on some simple operations to pgbench to see if it's competitive. Look into whether there's code in the PG wrapper they use that can be optimized usefully. There's two performance-related things that jump right out as things I'd want to confirm aren't causing issues: -It's a threaded design -The interesting tests look like they use prepared statements. I think the overall approach sysbench uses is good, it just needs some adjustments to work right against a PG database. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD