Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The patch also adds support for candidate matches. An index scan can indicate that the tuples it's returning are candidates, and the executor will recheck the original scan quals of any candidate matches when the tuple is fetched from heap.


This will not work, unless we change the planner --- the original quals
aren't necessarily there in some corner cases (partial indexes, if
memory serves).

This is only for bitmap scans, which *do* always have the original quals available in the executor (BitmapHeapScanState.bitmapqualorig). That's because we have to recheck the original conditions when the bitmap goes lossy.

To support candidate matches with the amgettuple API, that'll need to be changed as well. And that will indeed involve more executor changes.

The motivation for adding the support for candidate matches is that GIT / clustered indexes need it.

You need more than a vague reference to an unapplied patch to convince
me we ought to do this.

With the unapplied GIT patch, the index doesn't store the index key of every tuple. That has the consequence that when scanning, we get a bunch of tids to a heap page, we know that some of the might match, but we don't know which ones until the tuples are fetched from heap.

In a more distant future, range-encoded bitmap indexes will also produce candidate matches. And as I mentioned, this is immediately useful when doing bitmap ANDs large enough to go lossy.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to