Teodor Sigaev <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
