Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 321711DAC6D7 for ; Thu, 5 Jul 2012 22:42:37 -0300 (ADT) Received: from moutng.kundenserver.de ([212.227.17.10]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SmxZ6-00083M-0u for pgsql-performance@postgresql.org; Fri, 06 Jul 2012 01:42:36 +0000 Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MELXc-1Sc1Js0jEW-00FSxV; Fri, 06 Jul 2012 03:42:21 +0200 Message-ID: <4FF6427B.6080306@2ndQuadrant.com> Date: Thu, 05 Jul 2012 21:42:19 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16 MIME-Version: 1.0 To: Reza Taheri CC: "pgsql-performance@postgresql.org" , "Andy Bond (abond@redhat.com)" , Greg Kopczynski , Jignesh Shah Subject: Re: The need for clustered indexes to boost TPC-V performance References: <66CE997FB523C04E9749452273184C6C137CB88A86@exch-mbx-113.vmware.com> In-Reply-To: <66CE997FB523C04E9749452273184C6C137CB88A86@exch-mbx-113.vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:XEeKgRfKT3GMyYoKij1UN988W48RL+gOLcNU8MgU95y GDYX152HyW2VEHTfi5dLYth7wR1n0BYEffKk9dLXJk4jPFgdnm TQ46n2yi6Mw8d7l5ajsFjv1ry+CDtwiudvtJjTcJyeZR+V8fo9 TtbKNhKXHO3qsBJEZjkPEQjrqidRxCerHWt35IihWO5r6XY9Uq WgJ2ZVy7repjmP/NmkRE293T9cu4hc8Je+LXn1PTUG5+m5qV1l QkP7bW9vHbVqvNLcHNCOiwBc0q61NVfZCiYu8gSeCeXfqQxPoh f4zKvWQrVv7bLD16Urhc5Vc24ZP9nUMSpX/WWbdlI56RisrcOO 9AdkSeIqpUD8xi0gzRGE= X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/34 X-Sequence-Number: 47215 On 07/03/2012 07:13 PM, Reza Taheri wrote: > Is the PGSQL community willing to invest in a feature that a) has been > requested by many others already; and b) can make a huge difference in a > benchmark that can lend substantial credibility to PGSQL performance? Larger PostgreSQL features usually get built because companies sponsor their development, they pass review as both useful & correct, and then get committed. Asking the community to invest in a new feature isn't quite the right concept. Yes, everyone would like one of the smaller index representations. I'm sure we can find reviewers willing to look at such a feature and committers who would also be interested enough to commit it, on a volunteer basis. But a feature this size isn't going to spring to life based just on volunteer work. The most useful questions would be "who would be capable of writing that feature?" and "how can we get them sponsored to focus on it?" I can tell from your comments yet what role(s) in that process VMWare wants to take on internally, and which it's looking for help with. The job of convincing people it's a useful feature isn't necessary--we know that's true. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com