Re: Index AM change proposals, redux

Teodor Sigaev <teodor@sigaev.ru> writes:
>> * Proposed change to let both amgetnext and amgetmulti mark returned
>> tuples as "candidate matches", that is in need of rechecking of quals
>> ...
>> indexes).  There seemed to be some possible marginal use for it in GIST
>> indexes, but I'm not convinced that's a sufficient reason to complicate
>> the APIs.

> This is good way to eliminate awful operation '@@@' without performance loss.

Oh yeah, that kluge :-(.  Okay, that's probably a sufficient reason
all by itself.

>> * Proposed changes to allow amgetnext to return the actual index keys,
>> allowing certain types of "unindexable" quals to be checked without
>> having to fetch the heap entry.  For example a LIKE condition could be
>> fully checked against the index entry.  Since certain types of indexes
>> (GIN now, possibly hash in future) are incapable of doing this, there'd

> GiST too, because type of storage may be differ from type to be indexed. The 
> same touches GIN too.

Is this the case for *all* GiST and GIN indexes, or might we need a
per-index (rather than per-AM) flag to tell whether the original keys
are available?
        regards, tom lane