Re: ExecTidReScan exprCtxt

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ExecTidReScan exprCtxt
Date: 2009-12-29 00:19:49
Message-ID: 603c8f070912281619o77810ecam94fd9003ca70c743@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 28, 2009 at 2:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-12-29 00:20:31 Re: Serializable implementation
Previous Message Kevin Grittner 2009-12-29 00:05:12 Re: Admission Control Policy