Re: [HACKERS] postgres_fdw bug in 9.6
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] postgres_fdw bug in 9.6 |
Дата | |
Msg-id | 1460db7e-a848-9e7e-a09d-c2572914bcf3@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres_fdw bug in 9.6 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2016/12/23 1:04, Robert Haas wrote: > On Wed, Dec 21, 2016 at 11:04 AM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: >> Some review comments >> >> 1. postgres_fdw doesn't push down semi and anti joins so you may want to >> discount these two too. >> + jointype == JOIN_SEMI || >> + jointype == JOIN_ANTI); > But in the future, it might. I plan to work on adding those cases to postgres_fdw. > We shouldn't randomly leave foot-guns > lying around if there's an easy alternative. Some FDWs might have already supported pushing down semi/anti joins. So I think it's better to handle those joins as well. >> 3. Adding new members to JoinPathExtraData may save some work for postgres_fdw >> and other FDWs which would use CreateLocalJoinPath(), but it will add few bytes >> to the structure even when there is no "FULL foreign join which requires EPQ" >> involved in the query. That may not be so much of memory overhead since the >> structure is used locally to add_paths_to_joinrel(), but it might be something >> to think about. Instead, what if we call select_mergejoin_clauses() within >> CreateLocalJoinPath() to get that information? > I think that's exactly backwards. The few bytes of storage don't > matter, but extra CPU cycles might. I agree with Robert. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: