Re: postgres_fdw behaves oddly - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: postgres_fdw behaves oddly
Date
Msg-id 546C3FB3.4040503@lab.ntt.co.jp
Whole thread Raw
In response to Re: postgres_fdw behaves oddly  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
(2014/11/19 14:55), Etsuro Fujita wrote:
> (2014/11/18 18:37), Ashutosh Bapat wrote:
>> On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
>> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> wrote:
>>     (2014/11/17 19:54), Ashutosh Bapat wrote:
>
>>         Here are comments for postgres_fdw-syscol patch.

>>         3. Since there is already a testcase which triggered this
>> particular
>>         change, it will good, if we add that to regression in
>> postgres_fdw.
>
>>     Done.
>
>> I think, a better case would be SELECT * FROM ft1 t1, pg_class t2 WHERE
>> t1.tableoid = t2.oid. The condition makes sure that the tableoid in the
>> row is same as the OID of the foreign table recorded in pg_class
>> locally. And the EXPLAIN of the query which clearly shows that the
>> tableoid column in not fetched from the foreign server.
>
> I thought that test, but I didn't use it because I think we can't see
> (at least from the EXPLAIN) why the qual is not pushed down: the qual
> isn't pushed down possibly becasue the qual is considered as a *join*
> qual, not because the qual just cotains tableoid.  (Having said that, I
> think we can see if the qual isn't pushed down as a join qual for a
> parameterized plan, but ISTM it's worth complicating regression tests.)

Sorry, I incorrectly wrote the last sentence.  What I tried to write is, 
ISTM it's *not* worth complicating regression tests.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: postgres_fdw behaves oddly
Next
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw behaves oddly