Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-29 Thread PFC
On Sun, 27 May 2007 19:34:30 +0200, PFC [EMAIL PROTECTED] wrote: On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby [EMAIL PROTECTED] wrote: 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

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-29 Thread Jim Nasby
On May 27, 2007, at 12:34 PM, PFC wrote: On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby [EMAIL PROTECTED] wrote: 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,

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-29 Thread PFC
I assume you meant topic_id, post_id. :) Um, yes ;) The problem with your proposal is that it does nothing to ensure that posts for a topic stay together as soon as the table is large enough that you can't sort it in a single pass. If you've got a long-running thread, it's

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-27 Thread Jim C. Nasby
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

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-27 Thread PFC
On Sun, 27 May 2007 17:53:38 +0200, Jim C. Nasby [EMAIL PROTECTED] wrote: 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

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-27 Thread Alexander Staubo
On 5/27/07, PFC [EMAIL PROTECTED] wrote: PostgreSQL humiliates InnoDB on CPU-bound workloads (about 2x faster since I run it on dual core ; InnoDB uses only one core). However, InnoDB can automatically cluster tables without maintenance. How does it know what to cluster by? Does it

Re: [PERFORM] Feature suggestion : FAST CLUSTER

2007-05-27 Thread PFC
How does it know what to cluster by? Does it gather statistics about query patterns on which it can decide an optimal clustering, or does it merely follow a clustering previously set up by the user? Nothing fancy, InnoDB ALWAYS clusters on the primary key, whatever it is. So, if you can

[PERFORM] Feature suggestion : FAST CLUSTER

2007-05-22 Thread PFC
Well, CLUSTER is so slow (and it doesn't cluster the toast tables associated with the table to be clustered). However, when people use CLUSTER they use it to speed up their queries. For that the table does not need to be perfectly in-order. So, here is a new idea