Re: Optimization for updating foreign tables in Postgres FDW

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Optimization for updating foreign tables in Postgres FDW
Дата
Msg-id CA+TgmoYXkNJrBn7Y4PnU2HOzBbMt6cJM-m48j0wuJ86CwwVuFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimization for updating foreign tables in Postgres FDW  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Ответы Re: Optimization for updating foreign tables in Postgres FDW  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
On Wed, Dec 23, 2015 at 5:50 AM, Rushabh Lathia
<rushabh.lathia@gmail.com> wrote:
> +1.
>
> I like idea of separate FDW API for the DML Pushdown. Was thinking can't we
> can re-use the  IterateForeignScan(ForeignScanState *node) rather then
> introducing IterateDMLPushdown(ForeignScanState *node) new API ?

Yeah, I think we need to ask ourselves what advantage we're getting
out of adding any new core APIs.  Marking the scan as a pushed-down
update or delete has some benefit in terms of making the information
visible via EXPLAIN, but even that's a pretty thin benefit.  The
iterate method seems to just complicate the core code without any
benefit at all.  More generally, there is very, very little code in
this patch that accomplishes anything that could not be done just as
well with the existing methods.  So why are we even doing these core
changes?

Tom seemed to think that we could centralize some checks in the core
code, say, related to triggers, or to LIMIT.  But there's nothing like
that in this patch, so I'm not really understanding the point.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)