From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(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: | 2017-01-20 03:19:10 |
Message-ID: | 8ce359fd-00b1-a761-c17a-68fff893e90c@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/01/18 20:34, Ashutosh Bapat wrote:
> On Wed, Jan 18, 2017 at 8:18 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Done. Attached is the new version. I also adjusted the code a bit further.
> With this patch there are multiple cases, where CreateLocalJoinPath()
> would return NULL and hence postgres_fdw would not push a join down
> for example
> /*
> * (1) if either cheapest-total path is parameterized by the
> * other rel, we can't generate a hashjoin/mergejoin path, and
> * (2) proposed hashjoin/mergejoin path is still parameterized
> * (ie, the required_outer set calculated by
> * calc_non_nestloop_required_outer isn't NULL), it's not what
> * we want; which means that both the cheapest-total paths
> * should be unparameterized.
> */
> if (outer_path->param_info || inner_path->param_info)
> return NULL;
> or
> /*
> * If the cheapest-total outer path is parameterized by the
> * inner rel, we can't generate a nestloop path. (There's no
> * use looking for alternative outer paths, since it should
> * already be the least-parameterized available path.)
> */
> if (PATH_PARAM_BY_REL(outer_path, innerrel))
> return NULL;
> /* If proposed path is still parameterized, don't return it. */
> required_outer = calc_nestloop_required_outer(outer_path,
> inner_path);
> if (required_outer)
> {
> bms_free(required_outer);
> return NULL;
> }
>
> Am I right?
>
> The earlier version of this function GetExistingLocalJoinPath() used
> to return a local path in those cases and hence postgres_fdw was able
> to push down corresponding queries. So, we are introducing a
> performance regression.
Really? My understanding is: postgres_fdw will never have those cases
because it can always get the cheapest-total paths that are unparameterized.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-01-20 03:26:34 | Re: SearchSysCache, SysCacheGetAttr, and heap_getattr() |
Previous Message | Stephen Frost | 2017-01-20 03:14:40 | SearchSysCache, SysCacheGetAttr, and heap_getattr() |