Message-ID: <5BFD3EAD.2060301@lab.ntt.co.jp>
Date: Tue, 27 Nov 2018 21:55:09 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: postgres_fdw: oddity in costing aggregate pushdown paths
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
To: Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

Hi,

While working on [1], I noticed that since we don't set the selectivity
and cost of the local_conds (i.e., fpinfo->local_conds_sel and
fpinfo->local_conds_cost) properly in add_foreign_grouping_paths and
foreign_grouping_ok, estimate_path_cost_size produces considerably
underestimated results when use_remote_estimate.  I think this would
cause problems in later planning steps.  So, why not add something like
this to add_foreign_grouping_paths, as done in other functions such as
postgresGetForeignJopinPaths?

--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -5496,6 +5496,19 @@ add_foreign_grouping_paths(PlannerInfo *root,
RelOptInfo\
 *input_rel,
    if (!foreign_grouping_ok(root, grouped_rel, extra->havingQual))
        return;

+   /*
+    * Compute the selectivity and cost of the local_conds, so we don't have
+    * to do it over again for each path.  The best we can do for these
+    * conditions is to estimate selectivity on the basis of local
statistics.
+    */
+   fpinfo->local_conds_sel = clauselist_selectivity(root,
+                                                    fpinfo->local_conds,
+                                                    0,
+                                                    JOIN_INNER,
+                                                    NULL);
+
+   cost_qual_eval(&fpinfo->local_conds_cost, fpinfo->local_conds, root);
+
    /* Estimate the cost of push down */
    estimate_path_cost_size(root, grouped_rel, NIL, NIL, &rows,
                            &width, &startup_cost, &total_cost);

Best regards,
Etsuro Fujita

[1] https://www.postgresql.org/message-id/5BBC4140.50403%40lab.ntt.co.jp