About b-tree usage

Поиск
Список
Период
Сортировка
Искать
От
Ioannis Theoharis
Тема
About b-tree usage
Дата
Msg-id
Pine.GSO.4.58.0503062318290.14398@ourania.ics.forth.gr
Список
Дерево обсуждения
About b-tree usage Ioannis Theoharis <theohari@ics.forth.gr>
Re: About b-tree usage Jeff Davis <jdavis-pgsql@empires.org>
Re: About b-tree usage Ioannis Theoharis <theohari@ics.forth.gr>
Re: About b-tree usage Jeff Davis <jdavis-pgsql@empires.org>
Re: About b-tree usage Ioannis Theoharis <theohari@ics.forth.gr>
Re: About b-tree usage Jeff Davis <jdavis-pgsql@empires.org>
Re: About b-tree usage Klaus Naumann <lists@distinctmind.de>
Re: About b-tree usage Tom Lane <tgl@sss.pgh.pa.us>


Please let me know, if there is any option in postgresql to achieve the
following usage of a b-tree index:

For a relation R(att0, att1) and a btree index on attribute att0

In each insertion of a tuple on table:
- look on index if the value of att0 of new entry does already exist in index, and- if no, allow the aprorpiate entry on b-tree- if yes, do not allow an entry.

In my aplication i have always my relation clustered according to att0.
And the only information needed for a query with a range condition over
att0 in WHERE clause, is the place on disc where the first tuple with a
given value on att0 is placed.

The hint, is that beacause of too many raws of table, the index size is
too big. But the number of discrete values of att0 is orders of
magnitudes smaller than the number of tuples.

I try to investigate, if there is a way to use an alternative of b-tree
index, to decrease the blocks of indexed that are fetched into memory.

Thanks.



В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата:
От: Jeff Davis
Дата:
Сообщение: Re: About b-tree usage
FAQ