Re: rtree indexes aren't being used with 7.0

Jeff Hoffmann wrote:

> logically, i would say you're right about the bounding box being a
> descent judge of selectivity.  theoretically you should be able to see
> data distribution by looking at an rtree index which would give even a
> better selectivity number.  i'm still not sure about the cost thing,
> though.   would that be something that should be looked into?

after i wrote this, i noticed that all of the cost estimators use the
same generic cost estimator function (genericcostestimate) in which part
of the equation is the number of pages in the index.  i'm assuming that
this means disk pages, in which case, that would be part of the
problem.  rtree indexes are really bulky -- in fact, i have some index
files that are larger than the database file in a lot of cases, which
would almost immediately make a sequential scan interesting.  granted,
this is a funny case where there's only three attributes, but it
happens.  it might be useful to just modify the genericcostestimate
function and slash the indexPages into some fraction (e.g., an rtree
index on a box attribute is greater than 5x the size of a btree index on
an integer attribute, so maybe just cut the indexPages by 5 or 10 or
something like that.)  it's no substitute for a decent selectivity
function, but it might help.

am i anywhere near the right track here?

jeff