From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Can get GiST RECHECK clause to work |
Date: | 2004-06-13 22:08:45 |
Message-ID: | 10707.1087164525@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Cave-Ayland | 2004-06-13 22:50:49 | Re: Can get GiST RECHECK clause to work |
Previous Message | Alvaro Herrera | 2004-06-13 22:02:16 | Re: Nested transactions and tuple header info |