On Saturday 09 December 2006 03:48 Tom Lane's cat, walking on the keyboard,
wrote:
> Well, CLUSTER does not guarantee that the data remains sorted --- as
> soon as you do any updates it won't be anymore. So the planner can
> never assume that a plain seqscan delivers correctly sorted output.
And when the cluster is rebuilt? I mean, in theory, a clustered index should
be sorted at any point in time, that means I've got much cost for
insert/update cause I need to sort again the index when I'm performing the
insert/update, isn't it? For me, at least in theory, a clustered index is
always sorted. Now, assuming that my table is not changing (the number of
people hired/fired is very low!), it makes sense to me use a clustered index
cause I should not have the cost of insert/update but should have better
performances. Maybe I cannot understand something...
>
> The real question you should be asking in the above case is why it
> didn't use an indexscan on that index, and the answer is probably
> that you didn't ANALYZE. VACUUM does not update the statistics
> about index correlation.
I did run analyze, and the explain shows me the seq scan and then a sort. The
only difference I've seen between a only vacuum and a analyze is that the
seq. scan cost changes, but the final cost (i.e., seq. scan and sort) is the
same either with or without the index. This is the point I cannot understand.
And of course, as you stated, the problem is that the system is not
considering the created index (of course I can suggest it within the select
statement), and I don't know why.
Any explaination?
Thanks,
Luca
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
