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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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