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
