Andres Freund <andres@anarazel.de> writes:
> But an observation about how the code evolved lately (partially by me,
> don't get me wrong): I think we've too much smarts at execution
> time. IMO deduplicating transition states and such should much rather
> done at plan time, and if we do it right we'd also get rid of the uggly
> way AggState->aggs is built up...
I've looked at that before, and concluded that it wouldn't do that much
beyond shuffling code from point A to point B. What it would do that
I wouldn't like is widen the API between the planner and executor
(and everything else that looks at plan trees). For instance, most of
nodeAgg.c's internal structs would have to become public, creating
hazards if we need to change them in a minor release.
You could make an argument that having a better handle on the number of
transition states would give the planner a more accurate gauge of the
use of workmem in HashAgg --- but AFAICT, that is far from the number
one problem we have in hashagg memory estimation, so I can't get excited
about it.
Not saying "no", but I think it'd be a lot of work for not much return.
We have lots of other fish more worth frying.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs