Improve hash-agg performance
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org
Date: 2016-11-03T11:07:21Z
Lists: pgsql-hackers
Attachments
Hi, There's two things I found while working on faster expression evaluation, slot deforming and batched execution. As those two issues often seemed quite dominant cost-wise it seemed worthwhile to evaluate them independently. 1) We atm do one ExecProject() to compute each aggregate's arguments. Turns out it's noticeably faster to compute the argument for all aggregates in one go. Both because it reduces the amount of function call / moves more things into a relatively tight loop, and because it allows to deform all the required columns at once, rather than one-by-one. For a single aggregate it'd be faster to avoid ExecProject alltogether (i.e. directly evaluate the expression as we used to), but as soon you have two the new approach is faster. 2) For hash-aggs we right now we store the representative tuple using the input tuple's format, with unneeded columns set to NULL. That turns out to be expensive if the aggregated-on columns are not leading columns, because we have to skip over a potentially large number of NULLs. The fix here is to simply use a different tuple format for the hashtable. That doesn't cause overhead, because we already move columns in/out of the hashslot explicitly anyway. Comments? Regards, Andres Freund
Commits
-
User narrower representative tuples in the hash-agg hashtable.
- fc4b3dea2950 10.0 landed
-
Perform one only projection to compute agg arguments.
- 8ed3f11bb045 10.0 landed