Re: Scan Keys - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Scan Keys
Date
Msg-id 12545.1152197803@sss.pgh.pa.us
Whole thread Raw
In response to Scan Keys  (Greg Stark <gsstark@mit.edu>)
Responses Re: Scan Keys
List 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 by date:

Previous
From: "Leandro Oliveri"
Date:
Subject: unsubscribe
Next
From: Phil Frost
Date:
Subject: Re: lastval exposes information that currval does not