On Mon, Sep 01, 2008 at 12:25:26AM +0100, Gregory Stark wrote: > The problem is that it does a full index scan and looks up each tuple in the > order of the index. That means it a) is doing a lot of random i/o and b) has > to access the same pages over and over again.
<snip> > a) We need some way to decide *when* to do a sort and when to do an index > scan. The planner has all this machinery but we don't really have all the > pieces handy to use it in a utility statement. This is especially important > for the case where we're doing a cluster operation on a table that's already > clustered. In that case an index scan could conceivably actually win (though I > kind of doubt it). I don't really have a solution for this. The case I had recently was a table that was hugely bloated. 300MB data and only 110 live rows. A cluster was instant, a seqscan/sort would probably be much slower. A VACUUM FULL probably worse :) Isn't there some compromise. Like say scanning the index to collect a few thousand records and then sort them the way a bitmap index scan does. Should be much more efficient that what we have now. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature