Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 24D501337BE1 for ; Wed, 27 Apr 2011 17:44:55 -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 83792-01-6 for ; Wed, 27 Apr 2011 20:44:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gransy.com (mail.gransy.com [82.208.29.194]) by mail.postgresql.org (Postfix) with ESMTP id 173741337C0B for ; Wed, 27 Apr 2011 17:41:37 -0300 (ADT) Received: from [192.168.1.221] (ip-94-112-0-189.net.upcbroadband.cz [94.112.0.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 935A14A2244 for ; Wed, 27 Apr 2011 22:41:35 +0200 (CEST) Message-ID: <4DB87F7F.8060403@fuzzy.cz> Date: Wed, 27 Apr 2011 22:41:35 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101219 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: 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> In-Reply-To: <4DB820A0020000250003CF5C@gw.wicourts.gov> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-Spam-Level: X-Archive-Number: 201104/380 X-Sequence-Number: 43442 Dne 27.4.2011 20:56, Kevin Grittner napsal(a): > Greg Smith wrote: > >> The reason no work can be done in this area is because there are >> no standardized benchmarks of query execution in PostgreSQL being >> run regularly right now. Bringing up ideas for changing the >> computation is easy; proving that such a change is positive on >> enough workloads to be worth considering is the hard part. There >> is no useful discussion to be made on the hackers list that >> doesn't start with "here's the mix the benchmarks I intend to test >> this new model against". > > This is looming as an ever-more-acute need for the project, in > several areas. 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. regards Tomas