Re: FDW for PostgreSQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FDW for PostgreSQL
Date
Msg-id 14619.1352219749@sss.pgh.pa.us
Whole thread Raw
In response to Re: FDW for PostgreSQL  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: FDW for PostgreSQL  (花田 茂 <shigeru.hanada@gmail.com>)
List pgsql-hackers
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> 2012/11/6 Shigeru HANADA <shigeru.hanada@gmail.com>:
>> 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.

> Isn't it possible to pick-up only columns to be used in targetlist or
> local qualifiers, without modification of baserestrictinfo?

What the doc means to suggest is that you can look through the
baserestrictinfo list and then record information elsewhere about
interesting clauses you find.  If the FDW is actually *modifying* that
list, I agree that seems like a bad idea.  I don't recall anything in
the core system that does that, so it seems fragile.  The closest
parallel I can think of in the core system is indexscans pulling out
restriction clauses to use as index quals.  That code doesn't modify
the baserestrictinfo list, only make new lists with some of the same
entries.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Arguments to foreign tables?
Next
From: Robert Haas
Date:
Subject: Re: the number of pending entries in GIN index with FASTUPDATE=on