On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita <fujita.ets...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
