From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: RFC: planner statistics in 7.2 |
Date: | 2001-04-20 14:17:24 |
Message-ID: | 26094.987776244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-04-20 15:15:37 | Re: RFC: planner statistics in 7.2 |
Previous Message | Zeugswetter Andreas SB | 2001-04-20 09:58:23 | AW: RFC: planner statistics in 7.2 |