Re: FDW for PostgreSQL - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: FDW for PostgreSQL
Date
Msg-id CADyhKSVy1nx-otbjCdUCb5ZS9GrAyEs9oS3bWRx=LuHwXA-ncw@mail.gmail.com
Whole thread Raw
In response to Re: FDW for PostgreSQL  (Shigeru HANADA <shigeru.hanada@gmail.com>)
Responses Re: FDW for PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: FDW for PostgreSQL  (Shigeru Hanada <shigeru.hanada@gmail.com>)
List pgsql-hackers
2012/11/6 Shigeru HANADA <shigeru.hanada@gmail.com>:
> Sorry for delayed response.
>
> On Sun, Oct 21, 2012 at 3:16 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>
>> 2012/10/11 Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>:
>>
>>> I've reviewed your patch quickly.  I noticed that the patch has been
>>> created in
>>> a slightly different way from the guidelines:
>>> http://www.postgresql.org/docs/devel/static/fdw-planning.html  The
>>> guidelines
>>> say the following, but the patch identifies the clauses in
>>> baserel->baserestrictinfo in GetForeignRelSize, not GetForeignPaths.
>>> Also, it
>>> has been implemented so that most sub_expressions are evaluated at the
>>> remote
>>> end, not the local end, though I'm missing something.  For postgresql_fdw
>>> to be
>>> a good reference for FDW developers, ISTM it would be better that it be
>>> consistent with the guidelines.  I think it would be needed to update the
>>> following document or redesign the function to be consistent with the
>>> following
>>> document.
>>>
>> Hmm. It seems to me Fujita-san's comment is right.
>
>
> Indeed postgresql_fdw touches baserestrictinfo in GetForeignRelSize, but
> it's because of optimization for better width estimate.  The doc Fujita-san
> pointed says that:
>
>
>> The actual identification of such a clause should happen during
>> GetForeignPaths, since it would affect the cost estimate for the
>> path.
>
>
> I understood this description says that "you need to touch baserestrict info
> *before* GetForeignPlan to estimate costs of optimized path".  I don't feel
> that this description prohibits FDW to touch baserestrictinfo in
> GetForeignRelSize, but mentioning it clearly might be better.
>
Hanada-san,

Isn't it possible to pick-up only columns to be used in targetlist or
local qualifiers,
without modification of baserestrictinfo?
Unless we put WHERE clause on EXPLAIN statement for cost estimation on
GetForeignRelSize, all we have to know is list of columns to be fetched using
underlying queries. Once we construct a SELECT statement without WHERE
clause on GetForeignRelSize stage, it is never difficult to append it later
according to the same criteria being implemented at classifyConditions.

I'd like to see committer's opinion here.
Please give Hanada-san some directions.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



pgsql-hackers by date:

Previous
From: Shigeru HANADA
Date:
Subject: Re: FDW for PostgreSQL
Next
From: Amit Kapila
Date:
Subject: Re: Proposal [modified] for Allow postgresql.conf values to be changed via SQL