&numbatches,
&num_skew_mcvs);
virtualbuckets = (double) numbuckets *(double) numbatches;
+ /* mark the path with estimated # of batches */
+ path->num_batches = numbatches;
/*
* Determine bucketsize fraction for inner relation. We use the smallest
/* We don't want any excess columns in the hashed tuples */
disuse_physical_tlist(inner_plan, best_path->jpath.innerjoinpath);
+ /* If we expect batching, suppress excess columns in outer tuples too */
+ if (best_path->num_batches > 1)
+ disuse_physical_tlist(outer_plan, best_path->jpath.outerjoinpath);
+
/*
* If there is a single join clause and we can identify the outer
* variable as a simple column reference, supply its identity for
pathnode->jpath.outerjoinpath = outer_path;
pathnode->jpath.innerjoinpath = inner_path;
pathnode->jpath.joinrestrictinfo = restrict_clauses;
- /* A hashjoin never has pathkeys, since its ordering is unpredictable */
+ /*
+ * A hashjoin never has pathkeys, since its output ordering is
+ * unpredictable due to possible batching. XXX If the inner relation is
+ * small enough, we could instruct the executor that it must not batch,
+ * and then we could assume that the output inherits the outer relation's
+ * ordering, which might save a sort step. However there is considerable
+ * downside if our estimate of the inner relation size is badly off.
+ * For the moment we don't risk it. (Note also that if we wanted to take
+ * this seriously, joinpath.c would have to consider many more paths for
+ * the outer rel than it does now.)
+ */
pathnode->jpath.path.pathkeys = NIL;
pathnode->path_hashclauses = hashclauses;
+ /* cost_hashjoin will fill in pathnode->num_batches */
cost_hashjoin(pathnode, root, sjinfo);