From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw bug in 9.6 |
Date: | 2016-12-22 16:04:55 |
Message-ID: | CA+TgmoZyU_Lmp4j6JuZicEHAN4MkVZ8Boo24UKPq01yojRWYqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 21, 2016 at 11:04 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)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. We shouldn't randomly leave foot-guns
lying around if there's an easy alternative.
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-22 16:06:34 | Re: Hang in pldebugger after git commit : 98a64d0 |
Previous Message | Claudio Freire | 2016-12-22 15:22:25 | Re: Vacuum: allow usage of more than 1GB of work mem |