Re: FDW for PostgreSQL

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FDW for PostgreSQL
Date: 2012-11-06 10:36:50
Message-ID: CADyhKSVy1nx-otbjCdUCb5ZS9GrAyEs9oS3bWRx=LuHwXA-ncw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/11/6 Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>:
> Sorry for delayed response.
>
> On Sun, Oct 21, 2012 at 3:16 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>
>> 2012/10/11 Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2012-11-06 11:26:36 Re: Proposal [modified] for Allow postgresql.conf values to be changed via SQL
Previous Message Shigeru HANADA 2012-11-06 09:49:24 Re: FDW for PostgreSQL