Re: Scan Keys

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

In response to

  • Scan Keys at 2006-07-05 16:00:05 from Greg Stark

Responses

Browse pgsql-hackers by date

  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