Re: pgsql_fdw, FDW for PostgreSQL server

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql_fdw, FDW for PostgreSQL server
Дата
Msg-id 28680.1331304531@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql_fdw, FDW for PostgreSQL server  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: pgsql_fdw, FDW for PostgreSQL server
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Command Triggers, patch v11
Следующее
От: Robert Haas
Дата:
Сообщение: Re: logging in high performance systems.