From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw bug in 9.6 |
Date: | 2017-01-05 04:19:13 |
Message-ID: | CAFjFpReMOYDdE4wjiot9SBdOuUZLao0qVqe7yBnJt8N4GOdDKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>> Hmm. If I understand the patch correctly, it does not return any path
>> when merge join is allowed and there are merge clauses but no hash
>> clauses. In this case we will not create a foreign join path, loosing
>> some optimization. If we remove GetExistingLocalJoinPath, which
>> returns a path in those cases as well, we have a regression in
>> performance.
>
>
> Ok, will revise, but as I mentioned upthread, I'm not sure it's a good idea
> to search the pathlist to get a merge join even in this case. I'd vote for
> creating a merge join path from the inner/outer paths in this case as well.
> I think that would simplify the code as well.
Creating a new path 1. requires memory 2. spends CPU cycles in costing
and creating it 3. requires a search in inner and outer relations'
pathlists (see my earlier reply). Searching for an existing path just
requires a search in one relation's pathlist. The path should be
there. Why do we want to spend extra resources in creating a new path
when an old one exists and searching it is more efficient.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-01-05 04:30:42 | Re: Reporting planning time with EXPLAIN |
Previous Message | Ashutosh Bapat | 2017-01-05 04:15:15 | Re: postgres_fdw bug in 9.6 |