From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com> |
Cc: | Ian Harding <iharding(at)pakrat(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Re: Loading optimization |
Date: | 2001-01-09 17:59:45 |
Message-ID: | 1651.979063185@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com> writes:
> But does postgres actually use the fact that the data is clustered?
The planner has no idea that the table is clustered, and will estimate
indexscan costs on the assumption that the data is randomly ordered in
the table. So you're likely to get a seqscan plan for queries where
indexscan would actually be faster. This is something we need to fix,
but the main problem is accounting for the fact that the clustered order
will degrade over time as data is added/updated. See past discussions
in pghackers.
The CLUSTER implementation is so shoddy at the moment that I'm hesitant
to encourage people to use it anyway :-(. We've got to rewrite it so
that it doesn't drop other indexes, lose constraints, break foreign
key and inheritance relationships, etc etc.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-01-09 18:03:23 | Re: trouble with db-restore |
Previous Message | Tom Lane | 2001-01-09 17:49:37 | Re: shutting down postmasters |