Re: Scan Keys

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Scan Keys
Дата
Msg-id 12545.1152197803@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Scan Keys  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Scan Keys  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> I'm a bit confused about how scan keys work. Is there any simple way given a
> list of Datums of the same type as the index tuple attributes to get all
> matching index entries? This is for a non-system index.

Define "matching".

> I tried just using index_getprocinfo(...,BTORDER) with InvalidStrategy like
> btree does but _bt_preprocess_keys runs into problems without a valid strategy
> number. And in any case that would be btree specific which seems like it ought
> not be necessary.

There's no particularly good reason to suppose that a non-btree index
necessarily supports equality probes at all.  For instance if you're
using GIST or GIN for full-text searching, the index might only know
about component words, not the whole strings that are in the table.
Opclasses designed for spatial databases might conceivably not have
equality either (though that's a bit more of a stretch).

As Martijn pointed out, we rely on btree-opclass equality as the main
means of deciding what equality "really is".  I don't think it'd be
wise to insist that every index opclass, no matter what its purpose,
has to include an equality operator.
        regards, tom lane


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

Предыдущее
От: "Leandro Oliveri"
Дата:
Сообщение: unsubscribe
Следующее
От: Phil Frost
Дата:
Сообщение: Re: lastval exposes information that currval does not