Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
От | Etsuro Fujita |
---|---|
Тема | Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly |
Дата | |
Msg-id | 5A9CB7B9.2040008@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
|
Список | pgsql-hackers |
(2018/03/03 5:01), Robert Haas wrote: > On Fri, Mar 2, 2018 at 1:20 PM, Robert Haas<robertmhaas@gmail.com> wrote: >> On Fri, Mar 2, 2018 at 5:35 AM, Etsuro Fujita >> <fujita.etsuro@lab.ntt.co.jp> wrote: >>> Agreed. Better safe than sorry, so I disabled autovacuum for all the tables >>> created in the postgres_fdw regression test, except the ones with no data >>> modification created in the sections "test handling of collations" and "test >>> IMPORT FOREIGN SCHEMA". I'm attaching a patch for that. >> >> I have committed this patch. Whee! Thank you for taking the time on this! > And that seems to have made things worse. The failures on rhinocerous > look related: > > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=rhinoceros&br=HEAD Totally outdated stats used in query planning causes the failures? ANALYZE right before the plan-changing queries would fix the failures? > And so does this failure on chub: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chub&dt=2018-03-02%2016%3A10%3A02 The Git log shows that this was done before the commit. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: