Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group