Re: [HACKERS]
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] |
Дата | |
Msg-id | CAFjFpRcx-gJ+ks2jT7Tq=vB8U9KydYTdS99Nv2N+Un905=eXug@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: >> >> >>> 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 requires 1. memory 2. requires a search in inner > and outer relations' pathlist (see my reply to your objection about > unparameterized paths) 3. spends CPU cycles in costing the path as > well as creating it. Searching for an existing path requires a search > in only one relation's pathlist. The path should be there so we don't > need to construct a new one. The subject was removed from this reply for reasons unknown to me. Will reply again on the relevant thread. Sorry for the inconvenience. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: