Thread: ExecTidReScan exprCtxt
In ExecTidReScan, we have the following:
/* If we are being passed an outer tuple, save it for runtime
key calc */ if (exprCtxt != NULL) node->ss.ps.ps_ExprContext->ecxt_outertuple =
exprCtxt->ecxt_outertuple;
Is this dead code? I have been pouring through all the callers of
ExecReScan() and AFAICT the only place where we use an exprCtxt that
is neither pushed down from a higher-level executor node nor NULL is
in ExecNestLoop(). So I think that the only reason why we would need
this if we supported a nestloop with an inner tidscan. But I don't
think we do, nor do I see an obvious application for such a thing. A
romp through CVS history shows we have had some variant of this code
in ExecTidReScan since tid-scans were originally added, which makes me
suspicious that there was some point to this at least at one time, but
I haven't been able to figure out what it is/was.
...Robert
Robert Haas <robertmhaas@gmail.com> writes: > In ExecTidReScan, we have the following: > /* If we are being passed an outer tuple, save it for runtime > key calc */ > if (exprCtxt != NULL) > node->ss.ps.ps_ExprContext->ecxt_outertuple = > exprCtxt->ecxt_outertuple; > Is this dead code? I don't think it's reachable at the moment, but we do have interest in allowing joins using the TID value. See for example http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php http://archives.postgresql.org/pgsql-performance/2007-04/msg00231.php So I wouldn't be in favor of removing it. regards, tom lane
On Mon, Dec 28, 2009 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> In ExecTidReScan, we have the following: >> /* If we are being passed an outer tuple, save it for runtime >> key calc */ >> if (exprCtxt != NULL) >> node->ss.ps.ps_ExprContext->ecxt_outertuple = >> exprCtxt->ecxt_outertuple; > >> Is this dead code? > > I don't think it's reachable at the moment, but we do have interest > in allowing joins using the TID value. See for example > http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php > http://archives.postgresql.org/pgsql-performance/2007-04/msg00231.php > So I wouldn't be in favor of removing it. Hmm. If you're joining a table to itself on CTID, it seems that you would normally be able to optimize away the join completely. We've had some previous requests to do that when the join is on the primary key, and the CTID is an even more clear-cut case. ...Robert