Re: Scan Keys

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> > 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).

AFAIK even GIST indexes can fetch me a reasonably limited list of tuples that
might be equal. It might include significantly more tuples than just what I'm
looking for but it's much better than doing a full index scan.

But on that note, is it ok to use the bulkdelete index AM methods for
non-vacuum purposes as long as there's only one such process running at a
time? Presumably that means taking an ShareUpdateExclusiveLock on the
indexrelation or a ExclusiveLock on the pg_index line?

> 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.

I'm having trouble picturing any useful index where there's no operator close
to equality. But I'll concede that that may be a failure of my imagination :)

--
greg