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
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 |