Re: [HACKERS] postgres_fdw bug in 9.6
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] postgres_fdw bug in 9.6 |
Дата | |
Msg-id | ac14dcb8-5bd6-2d17-f68b-a64daf430da6@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres_fdw bug in 9.6 (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On 2017/01/11 19:26, Ashutosh Bapat wrote: > On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita > <fujita.etsuro@lab.ntt.co.jp> wrote: >> On 2017/01/11 17:51, Ashutosh Bapat wrote: >>> On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita >>> <fujita.etsuro@lab.ntt.co.jp> wrote: >>>> On 2017/01/11 13:40, Ashutosh Bapat wrote: >>>>> Or it can >>>>> have foreign paths in there, which will need redirection. That's not >>>>> very good. >>>> Maybe I'm missing something, but redirection isn't a problem. >>> Peformance wise it is, correctness-wise it is not. Why do we want to >>> incur a hop, when we can avoid it. >> ISTM that's solving a problem that hasn't been proven to be a problem. > A hop will consume a function call worth CPU at least. Is that a problem in practice? >>>>> 2. Fix existing code by applying patch from [1] >>>> As I said before, that might be fine for 9.6, but I don't think it's a >>>> good >>>> idea to search the pathlist because once we support parameterized foreign >>>> join paths, which is on my TODOs, we would have to traverse through the >>>> possibly-lengthy pathlist to find a local-join path, as mentioned in [3]. >>> I don't agree that pathlists will be long enough to make this a >>> non-attractive solution. For parameterized foreign join paths, with >>> the approach that this patch takes, we will require to search in two >>> such pathlists, inner and outer. >> Sorry, I don't understand this part. > A parameterized join is built if the joining paths are parameterized > as well. Thus building a parameterized local path would require one > to search suitably parameterized paths in joining relations in their > pathlists. Yeah, I'm thinking to (1) create parameterized foreign-join paths from the cheapest_parameterized_paths lists of the outer and inner rels, and (2) create a local-join paths for any parameterized foreign-join path from the component paths chosen from the lists in a similar way as CreateLocalJoinPath creates an unparameterized local-join path from the cheapest-total-cost paths of the outer and inner rels. That's the real reason why I'm proposing to replace GetExistingLocalJoinPath with CreateLocalJoinPath. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: