On Tue, May 22, 2007 at 09:29:00AM +0200, PFC wrote: > This does not run a complete sort on the table. It would be about as > fast as your seq scan disk throughput. Obviously, the end result is > not as > good as a real CLUSTER since the table will be made up of several ordered > chunks and a range lookup. Therefore, a range lookup on the clustered > columns would need at most N seeks, versus 1 for a really clustered table. > But it only scans the table once and writes it once, even counting index > rebuild.
Do you have any data that indicates such an arrangement would be substantially better than less-clustered data? -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpxnzY69XnoC.pgp
Description: PGP signature
