On Wed, Aug 15, 2012 at 6:43 AM, Doug Hunley <doug.hunley@xxxxxxxxx> wrote: > On Tue, Aug 14, 2012 at 1:29 PM, ktm@xxxxxxxx <ktm@xxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
