On 2017/01/18 20:34, Ashutosh Bapat wrote:
On Wed, Jan 18, 2017 at 8:18 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
