Re: Optimization for updating foreign tables in Postgres FDW
От | Shigeru Hanada |
---|---|
Тема | Re: Optimization for updating foreign tables in Postgres FDW |
Дата | |
Msg-id | CAEZqfEdMJkg30bA7D6pvhJy+2W3mQKHf2gHK+WfHPs+aMT956Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Optimization for updating foreign tables in Postgres FDW (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Optimization for updating foreign tables in Postgres
FDW
(Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
|
Список | pgsql-hackers |
Hi Fujita-san, Issues addressed by Eitoku-san were fixed properly, but he found a bug and a possible enhancement in the v2 patch. * push-down check misses delete triggers update_is_pushdown_safe() seems to have a bug that it misses the existence of row-level delete trigger. DELETE statement executed against a foreign table which has row-level delete trigger is pushed down to remote, and consequently no row-level delete trigger is fired. * further optimization Is there any chance to consider further optimization by passing the operation type (UPDATE|DELETE) of undergoing statement to update_is_pushdown_safe()? It seems safe to push down UPDATE statement when the target foreign table has no update trigger even it has a delete trigger (of course the opposite combination would be also fine). * Documentation The requirement of pushing down UPDATE/DELETE statements would not be easy to understand for non-expert users, so it seems that there is a room to enhance documentation. An idea is to define which expression is safe to send to remote first (it might need to mention the difference of semantics), and refer the definition from the place describing the requirement of pushing-down for SELECT, UPDATE and DELETE. 2014-08-04 20:30 GMT+09:00 Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>: > (2014/07/30 17:22), Etsuro Fujita wrote: >> >> (2014/07/29 0:58), Robert Haas wrote: >>> >>> On Fri, Jul 25, 2014 at 3:39 AM, Albe Laurenz >>> <laurenz.albe@wien.gv.at> wrote: >>>> >>>> Shigeru Hanada wrote: >>>>> >>>>> * Naming of new behavior >>>>> You named this optimization "Direct Update", but I'm not sure that >>>>> this is intuitive enough to express this behavior. I would like to >>>>> hear opinions of native speakers. >>>> >>>> >>>> How about "batch foreign update" or "batch foreign modification"? >>>> (Disclaimer: I'm not a native speaker either.) >>> >>> >>> I think direct update sounds pretty good. "Batch" does not sound as >>> good to me, since it doesn't clearly describe what makes this patch >>> special as opposed to some other grouping of updates that happens to >>> produce a speedup. >> >> >> I agree with Robert on that point. >> >>> Another term that might be used is "update pushdown", since we are >>> pushing the whole update to the remote server instead of having the >>> local server participate. Without looking at the patch, I don't have >>> a strong opinion on whether that's better than "direct update" in this >>> context. >> >> >> "Update Pushdown" is fine with me. >> >> If there are no objections of others, I'll change the name from "Direct >> Update" to "Update Pushdown". > > > Done. (I've left deparseDirectUpdateSql/deparseDirectDeleteSql as-is, > though.) > > Other changes: > > * Address the comments from Eitoku-san. > * Add regression tests. > * Fix a bug, which fails to show the actual row counts in EXPLAIN ANALYZE > for UPDATE/DELETE without a RETURNING clause. > * Rebase to HEAD. > > Please find attached an updated version of the patch. > > > Thanks, > > Best regards, > Etsuro Fujita -- Shigeru HANADA
В списке pgsql-hackers по дате отправления: