Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 251E71337B80 for ; Wed, 27 Apr 2011 18:55:53 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 63096-08 for ; Wed, 27 Apr 2011 21:55:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id 0EC8D1337BCF for ; Wed, 27 Apr 2011 18:55:45 -0300 (ADT) Received: from [192.168.1.3] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Mddoi-1QRMpf0SC4-00PIiZ; Wed, 27 Apr 2011 23:55:44 +0200 Message-ID: <4DB890D8.5000604@2ndquadrant.com> Date: Wed, 27 Apr 2011 17:55:36 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Tomas Vondra CC: pgsql-performance@postgresql.org Subject: Re: Performance References: <20110412171855.GA14292@tux> <4DA496FA.3070908@fuzzy.cz> <8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com> <4DA4BFA2.5060601@fuzzy.cz> <4DA4D40A.4010200@fuzzy.cz> <4DA56DA8020000250003C783@gw.wicourts.gov> <4DA6216E.9020907@fuzzy.cz> <4DA63125.5070106@fuzzy.cz> <5c6c67e9f0c4abed2b7ac84e83fe1f32.squirrel@sq.gransy.com> <4DB8652D.7010804@2ndquadrant.com> <4DB820A0020000250003CF5C@gw.wicourts.gov> <4DB87F7F.8060403@fuzzy.cz> In-Reply-To: <4DB87F7F.8060403@fuzzy.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:tY/pkzHJjoJtdKRcTS47pkFbqGC1AqOrVHI+ZrsJ6+2 zbGC3lOBC7Fbki+TbTABevwOnU+lnNsaZ5gzbkDcT9/DaA6DcR DzEnQohu5NZJIaK3LvPILWXtCOpaPvdjgHORQWnMyuoPg9sI4E aSF+/r+pu7lhEJUrSffgsdtMU/kEvb5SU6MzVgtWakPPF8Bpdm rho9M96+YKk30VGLL0hEk1AuEBVNl8KhRBC/YwM9/Y= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201104/383 X-Sequence-Number: 43445 Tomas Vondra wrote: > Hmmm, just wondering - what would be needed to build such 'workload > library'? Building it from scratch is not feasible IMHO, but I guess > people could provide their own scripts (as simple as 'set up a a bunch > of tables, fill it with data, run some queries') and there's a pile of > such examples in the pgsql-performance list. > The easiest place to start is by re-using the work already done by the TPC for benchmarking commercial databases. There are ports of the TPC workloads to PostgreSQL available in the DBT-2, DBT-3, and DBT-5 tests; see http://wiki.postgresql.org/wiki/Category:Benchmarking for initial information on those (the page on TPC-H is quite relevant too). I'd like to see all three of those DBT tests running regularly, as well as two tests it's possible to simulate with pgbench or sysbench: an in-cache read-only test, and a write as fast as possible test. The main problem with re-using posts from this list for workload testing is getting an appropriately sized data set for them that stays relevant. The nature of this sort of benchmark always includes some notion of the size of the database, and you get different results based on how large things are relative to RAM and the database parameters. That said, some sort of systematic collection of "hard queries" would also be a very useful project for someone to take on. People show up regularly who want to play with the optimizer in some way. It's still possible to do that by targeting specific queries you want to accelerate, where it's obvious (or, more likely, hard but still straightforward) how to do better. But I don't think any of these proposed exercises adjusting the caching model or default optimizer parameters in the database is going anywhere without some sort of benchmarking framework for evaluating the results. And the TPC tests are a reasonable place to start. They're a good mixed set of queries, and improving results on those does turn into a real commercial benefit to PostgreSQL in the future too. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books