"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> I'm trying to mark a GiST index as lossy using the RECHECK operator as
> part of some work on PostGIS, but what happens is that the original
> operator function is never reapplied to the results of the index scan.
You sure? I'm pretty sure that a number of the contrib gist index
opclasses would fail their regression tests if this were broken.
As of 7.5 you cannot see the reapplication in the generated plan's
filter condition; perhaps that got you confused?
2004-01-05 23:31 tgl
* src/: backend/executor/nodeIndexscan.c,
backend/nodes/copyfuncs.c, backend/nodes/outfuncs.c,
backend/optimizer/path/costsize.c,
backend/optimizer/plan/createplan.c,
backend/optimizer/plan/setrefs.c, include/nodes/execnodes.h,
include/nodes/plannodes.h: Instead of rechecking lossy index
operators by putting them into the regular qpqual ('filter
condition'), add special-purpose code to nodeIndexscan.c to recheck
them. This ends being almost no net addition of code, because the
removal of planner code balances out the extra executor code, but
it is significantly more efficient when a lossy operator is
involved in an OR indexscan. The old implementation had to recheck
the entire indexqual in such cases.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
