Tom Lane <[EMAIL PROTECTED]> 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).
Advertising
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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
