On 2017/01/05 21:38, Ashutosh Bapat wrote:
> On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>>> On 2017/01/03 17:28, Ashutosh Bapat wrote:
>>>>> Also, in this function, if fpinfo->tlist is already set, why do we want
>>>>> to
>>>>> build it again?
>>> IIUC, for a relation with use_remote_estimates we will deparse the
>>> query twice and will build the targetlist twice.
>> That's right. We could avoid the duplicate work the way you proposed, but I
>> was thinking to leave that for another patch. Should we do that in this
>> patch?
> If you are agree that the change is needed, it's better to do it in
> this patch itself if we can, instead of a one liner patch.
While working on this, I noticed a weird case. Consider:
postgres=# explain verbose select 1 from ft1 left join ft2 on (ft1.a =
ft2.a) inner join test on (true); QUERY PLAN
------------------------------------------------------------------------------------------------- Nested Loop
(cost=100.00..103.06rows=1 width=4) Output: 1 -> Foreign Scan (cost=100.00..102.04 rows=1 width=0)
Relations:(public.ft1) LEFT JOIN (public.ft2) Remote SQL: SELECT NULL FROM (public.t1 r1 LEFT JOIN public.t2
r2 ON (((r1.a = r2.a)))) -> Seq Scan on public.test (cost=0.00..1.01 rows=1 width=0) Output: test.a,
test.b
(7 rows)
In this case the fpinfo->tlist of the foreign join is NIL, so whether or
not the tlist is already built cannot be discriminated by the
fpinfo->tlist. We might need another flag to show that the tlist has
been built already. Since this is an existing issue and we would need
to give careful thought to this, so I'd like to leave this for another
patch.
Best regards,
Etsuro Fujita
