Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1km7-00011k-Ly for pgsql-performance@postgresql.org; Wed, 15 Aug 2012 21:05:11 +0000 Received: from smtp.01.com ([199.36.142.181]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1km6-00027p-LM for pgsql-performance@postgresql.org; Wed, 15 Aug 2012 21:05:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3841E2940DB for ; Wed, 15 Aug 2012 16:05:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-cUxpy01Yr3 for ; Wed, 15 Aug 2012 16:05:10 -0500 (CDT) Received: from smtp.01.com (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0CA7729401D for ; Wed, 15 Aug 2012 16:05:10 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-143-92.dsl.dynamic.sonic.net [70.36.143.92]) by smtp-out-1.01.com (Postfix) with ESMTPSA id C0756294229 for ; Wed, 15 Aug 2012 16:05:09 -0500 (CDT) Message-ID: <502C0F0E.2010503@agliodbs.com> Date: Wed, 15 Aug 2012 14:05:18 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: cluster on conditional index? References: <20120814172910.GP27500@aart.rice.edu> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/88 X-Sequence-Number: 47626 > That actually makes sense to me. Cluster the rows covered by that > index, let the rest fall where they may. I'm typically only accessing > the rows covered by that index, so I'd get the benefit of the cluster > command but wouldn't have to spend cycles doing the cluster for rows I > don't care about. Sure, that's a feature request though. And thinking about it, I'm willing to bet that it's far harder to implement than it sounds. In the meantime, you could ad-hoc this by splitting the table into two partitions and clustering one of the two partitions. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com