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 still
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, t
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
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 ha
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 ga
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
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
>
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 for