Re: Can get GiST RECHECK clause to work
От | Tom Lane |
---|---|
Тема | Re: Can get GiST RECHECK clause to work |
Дата | |
Msg-id | 10707.1087164525@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Can get GiST RECHECK clause to work ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>) |
Список | pgsql-hackers |
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.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 indexoperators by putting them into the regularqpqual ('filtercondition'), add special-purpose code to nodeIndexscan.c to recheckthem. This ends being almost nonet addition of code, because theremoval of planner code balances out the extra executor code, butit is significantly moreefficient when a lossy operator isinvolved in an OR indexscan. The old implementation had to recheckthe entire indexqualin such cases. regards, tom lane
В списке pgsql-hackers по дате отправления: