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
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 |