On Thu, Apr 20, 2017 at 4:16 PM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > but cost this without numGroups. > > /* > * The transCost.per_tuple component of aggcosts should be charged once > * per input tuple, corresponding to the costs of evaluating the aggregate > * transfns and their input expressions (with any startup cost of course > * charged but once). The finalCost component is charged once per output > * tuple, corresponding to the costs of evaluating the finalfns. > * > * If we are grouping, we charge an additional cpu_operator_cost per > * grouping column per input tuple for grouping comparisons. > * > > The reason may be that hashing isn't as costly as a comparison. I > don't how true is that.
Earlier in GatherMerge thread[1], Rushabh mentioned that hashAggregate is getting picked where actually grouping aggregate with GatherMerge was faster during actual execution time and he suspected problems with costing of hashAggregate. Maybe this is one of those? [1]https://www.postgresql.org/message-id/CAGPqQf2164iV6k-_M75qEZWiCfRarA_SKSmHjc0Uh1rEf5RJrA%40mail.gmail.com -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
