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 decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
