Re: pgsql_fdw, FDW for PostgreSQL server - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql_fdw, FDW for PostgreSQL server
Date
Msg-id 28680.1331304531@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql_fdw, FDW for PostgreSQL server  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: pgsql_fdw, FDW for PostgreSQL server  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> (2012/03/09 14:00), Tom Lane wrote:
>> Attached is a draft patch for that.

> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant. 
>   Why not use RelOptInfo.pages and RelOptInfo.tuples?

I intentionally avoided setting RelOptInfo.pages because that would have
other effects on planning (cf total_table_pages or whatever it's
called).  It's possible that that would actually be desirable, depending
on whether you think the external file should be counted as part of the
query's disk-access footprint; but it would take some investigation to
conclude that, which I didn't feel like doing right now.  Likewise, I'm
not sure offhand what side effects might occur from using
RelOptInfo.tuples, and didn't want to change file_fdw's behavior without
more checking.

> 2. IMHO RelOptInfo.fdw_private seems confusing.  How about renaming it 
> to e.g., RelOptInfo.fdw_state?

Why is that better?  It seems just as open to confusion with another
field (ie, the execution-time fdw_state).  I thought for a little bit
about trying to give different names to all four of the fdw private
fields (RelOptInfo, Path, Plan, PlanState) but it's not obvious what
naming rule to use, and at least the last two of those can't be changed
without breaking existing FDW code.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Command Triggers, patch v11
Next
From: Robert Haas
Date:
Subject: Re: logging in high performance systems.