Skip site navigation (1) Skip section navigation (2)

Re: cluster on conditional index?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Doug Hunley <doug(dot)hunley(at)gmail(dot)com>
Cc: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: cluster on conditional index?
Date: 2012-08-16 16:04:12
Message-ID: CAMkU=1zYwoHHsqJ8wfK3GdG_t_a6t4RK-GFDSKymQ0EGP=typA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Wed, Aug 15, 2012 at 6:43 AM, Doug Hunley <doug(dot)hunley(at)gmail(dot)com> wrote:
> On Tue, Aug 14, 2012 at 1:29 PM, ktm(at)rice(dot)edu <ktm(at)rice(dot)edu> wrote:
>>
>> It probably has to do with the fact that a conditional index, does
>> not include every possible row in the table. Although, a "cluster" of
>> the matching rows and then leave the rest in place, should work. How
>> is that for hand-waving.  :)
>>
>
> 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.

IIRC, there isn't currently an in-place version of CLUSTER, it always
rewrites the entire table.  So it would still have to do something
with those rows, so that they show up in the new table.  But it could
just treat them all as equal to one another and have them be in
whatever order they happen to fall in.

Cheers,

Jeff


In response to

pgsql-performance by date

Next:From: anarazel@anarazel.deDate: 2012-08-16 16:07:26
Subject: Re: High Disk write and space taken by PostgreSQL
Previous:From: Scott MarloweDate: 2012-08-16 15:49:53
Subject: Re: High Disk write and space taken by PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group