At 22:27 19/04/01 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>> At 21:14 19/04/01 -0400, Tom Lane wrote:
>>> But you don't really need to look at the index (if it even exists
>>> at the time you do the ANALYZE). The extent to which the data is
>>> ordered in the table is a property of the table, not the index.
>
>> But the value (and cost) of using a specific index in an indexscan depends
>> on that index (or am I missing something?).
>
>All that we're discussing here is one specific parameter in the cost
>estimation for an indexscan, viz, the extent to which the table ordering
>agrees with the index ordering.
This does not necessarily follow. A table ordering need not follow the sort
order of an index for the index to have a low indexscan cost. All that is
required is that most of the rows referred to by an index node must reside
in a page or pages that will be read by one IO. eg. a table that has a
sequence based ID, with, say 20% of rows updated, will work nicely with an
indexscan on the ID, even though it has never been clustered.
What I'm suggesting is that if you look at a random sample of index nodes,
you should be able to get a statistically valid estimate of the 'clumping'
of the data pointed to by the index.
Am I still missing the point?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
