Re: Push down more full joins in postgres_fdw
От | Ashutosh Bapat |
---|---|
Тема | Re: Push down more full joins in postgres_fdw |
Дата | |
Msg-id | CAFjFpRfvToXgJhFAv7V3WPx8qEU66GJT-+we6d04n4nTaOtB5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Push down more full joins in postgres_fdw (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Push down more full joins in postgres_fdw
|
Список | pgsql-hackers |
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote: > On 2016/10/26 18:25, Ashutosh Bapat wrote: > >> Your patch calls isSubqueryExpr() recursively for every Var in the >> targetlist, which can be many for foreign tables with many columns. >> For every such Var it may need to reach upto the relation which is >> converted into subquery, which can as bad as reaching every base >> relation. So, it looks like the number of recursive calls to >> isSubqueryExpr() is bounded by V * N (i.e. worst case depth of the >> RelOptInfo tree), which can be quite costly. If use_remote_estimates >> is true, we do this for every intermediate relation and for every path >> created. That isn't very performance efficient. > > > In practice, the search cost would be negligible compared to the cost of > explaining/executing the query. > > My concern about your proposal is: it might not be worth complicating the > code to solve a problem that is actually not a problem in practice. > To me the current code looks complicated esp. because of the recursion involved and usage of out parameters to isSubqueryExpr(). My suggestion goes inline with the current method of deparsing a Var. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: