Re: Can get GiST RECHECK clause to work

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

In response to

Browse pgsql-hackers by date

  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