Обсуждение: ExecTidReScan exprCtxt

Поиск
Список
Период
Сортировка

ExecTidReScan exprCtxt

От
Robert Haas
Дата:
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


Re: ExecTidReScan exprCtxt

От
Tom Lane
Дата:
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


Re: ExecTidReScan exprCtxt

От
Robert Haas
Дата:
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