In cost_size.c, there is this comment block:

+        * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly
+        * same total CPU cost, but AGG_SORTED has lower startup cost.  If
+        * input path is already sorted appropriately, AGG_SORTED should be
+        * preferred (since it has no risk of memory overflow).  This will
+        * as long as the computed total costs are indeed exactly equal ---
+        * if there's roundoff error we might do the wrong thing.  So be
+        * that the computations below form the same intermediate values in
+        * same order.

But, why should they have the same cost in the first place?  A sorted
aggregation just has to do an equality comparison on each adjacent pair,
which is costed as (cpu_operator_cost * numGroupCols) * input_tuples.   A
hash aggregation has to do a hashcode computation for each input, which
apparently is also costed at (cpu_operator_cost * numGroupCols) *
input_tuples.  But it also has to do the equality comparison between the
input tuple and any aggregation it is about to be aggregated into, to make
sure the hashcode is not a false collision.  That should be
another (cpu_operator_cost * numGroupCols) * (input_tuples - numGroups),
shouldn't it?  Currently, that is apparently assumed to be free.

Is there something here I am overlooking?



Reply via email to