> * 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.
> * 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.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/