From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Scan Keys |
Date: | 2006-07-06 14:56:43 |
Message-ID: | 12545.1152197803@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Phil Frost | 2006-07-06 15:02:25 | Re: lastval exposes information that currval does not |
Previous Message | Leandro Oliveri | 2006-07-06 13:54:12 | unsubscribe |