Re: RFC: planner statistics in 7.2

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   |/