I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I remember that last spring, in the context of GIT, you were worried
>> about the performance implication of preparing to recheck rows when no
>> rechecks are needed. I didn't quite buy that back then, but this would
>> have the same issue.
> As I mentioned upthread, it appears that we're paying that overhead
> anyway --- at least nodeIndexscan.c thinks we are. I need to dig into
> the planner a bit today and see whether it's taking any shortcuts for
> non-RECHECK operators.
Yeah, we are paying that overhead. The reason is that the planner
always constructs an "indexqualorig" expression and the executor
always initializes it. The only place where it's used currently in
a plain indexscan is for EvalPlanQual rechecking, but we could certainly
use it for lossy-operator rechecking. (The implication of this is that
if any of the operators in a multi-index-qual indexscan are lossy, we'd
recheck all of them upon fetching the heap tuple. Does anyone feel
that's not good enough? Most of the practical cases I can think of
for multi-operator scans are for btree anyway, so it's not clear that
there's much value in complicating matters to evaluate just some of the
indexqualorig clauses.)
This would effectively move *all* management of lossy operators to
runtime; the planner wouldn't really think about it at all. We could
simplify createplan.c a bit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
