Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Feature suggestion : FAST CLUSTER
- From: "Jim C. Nasby" <decibel(at)decibel(dot)org>
- To: PFC <lists(at)peufeu(dot)com>
- Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
- Subject: Re: Feature suggestion : FAST CLUSTER
- Date: Sun, 27 May 2007 10:53:38 -0500
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(at)decibel(dot)org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgpKX4QadCaQY.pgp
Description: PGP signature
- Follow-Ups:
- Re: Feature suggestion : FAST CLUSTER
- From: PFC
- Re: Feature suggestion : FAST CLUSTER
- References:
- Feature suggestion : FAST CLUSTER
- From: PFC
- Feature suggestion : FAST CLUSTER
- Prev by Date: Re: ECC RAM really needed?
- Next by Date: Re: Domains versus Check Constraints
- Previous by thread: Feature suggestion : FAST CLUSTER
- Next by thread: Re: Feature suggestion : FAST CLUSTER
- Indexes: