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

Think compound, ascending, descending and functional index.
The (let's call it) cluster statistic for estimating indexscan cost can only 
be deduced from the index itself (for all but the simplest one column btree). 

Andreas

Fri, 20 Apr 2001 11:58:23 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: RFC: planner statistics in 7.2 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
>> 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.

> Think compound, ascending, descending and functional index.
> The (let's call it) cluster statistic for estimating indexscan cost can only 
> be deduced from the index itself (for all but the simplest one column btree).

If you want to write code that handles those cases, go right ahead ;-).
I think it's sufficient to look at the first column of a multicolumn
index for cluster-order estimation --- remember all these numbers are
pretty crude anyway.  We have no such thing as a "descending index";
and I'm not going to worry about clustering estimation for functional
indexes.

			regards, tom lane

Fri, 20 Apr 2001 10:17:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: RFC: planner statistics in 7.2 