| From: | "Jim C(dot) 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: | 2007-05-27 15:53:38 |
| Message-ID: | 20070527155338.GM92628@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2007-05-27 15:59:42 | Re: Domains versus Check Constraints |
| Previous Message | Andrew Sullivan | 2007-05-27 14:27:08 | Re: ECC RAM really needed? |