Re: rtree indexes aren't being used with 7.0

Поиск
Список
Период
Сортировка
От Jeff Hoffmann
Тема Re: rtree indexes aren't being used with 7.0
Дата
Msg-id 392048B8.A777CCCA@propertykey.com
обсуждение исходный текст
Ответ на Re: rtree indexes aren't being used with 7.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: rtree indexes aren't being used with 7.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
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

В списке pgsql-general по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Best way to "add" columns
Следующее
От: Jeff Hoffmann
Дата:
Сообщение: Re: rtree indexes aren't being used with 7.0