| От | Etsuro Fujita |
|---|---|
| Тема | Re: [HACKERS] postgres_fdw bug in 9.6 |
| Дата | |
| Msg-id | 5A6195D8.8060206@lab.ntt.co.jp обсуждение |
| Ответ на | Re: [HACKERS] postgres_fdw bug in 9.6 (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
| Ответы |
Re: [HACKERS] postgres_fdw bug in 9.6
|
| Список | pgsql-hackers |
(2018/01/18 15:40), Etsuro Fujita wrote: > (2018/01/18 7:09), Robert Haas wrote: >> On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> It's debatable perhaps -- I tend to err in the other direction. >>> But likewise, I don't care deeply. Just push it ... >> >> Done. I noticed that this test case added by the patch is not appropriate: +-- multi-way join involving multiple merge joins +EXPLAIN (VERBOSE, COSTS OFF) +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1 + AND ft1.c1 = ft5.c1 FOR UPDATE; +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1 + AND ft1.c1 = ft5.c1 FOR UPDATE; because it doesn't inject extra Sort nodes into EPQ recheck plans, so it works well without the fix. I modified this to inject a Sort into the recheck plan of the very first foreign join. Attached is a patch for that. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера