Allow aggregates to provide estimates of their transition state data size.
Formerly the planner had a hard-wired rule of thumb for guessing the amount
of space consumed by an aggregate function's transition state data. This
estimate is critical to deciding whether it's OK to use hash aggregation,
and in many situations the built-in estimate isn't very good. This patch
adds a column to pg_aggregate wherein a per-aggregate estimate can be
provided, overriding the planner's default, and infrastructure for setting
the column via CREATE AGGREGATE.
It may be that additional smarts will be required in future, perhaps even
a per-aggregate estimation function. But this is already a step forward.
This is extracted from a larger patch to improve the performance of numeric
and int8 aggregates. I (tgl) thought it was worth reviewing and committing
this infrastructure separately. In this commit, all built-in aggregates
are given aggtransspace = 0, so no behavior should change.
Hadi Moshayedi, reviewed by Pavel Stehule and Tomas Vondra
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/6cb86143e8e1e855255edc706bce71c6ebfd9a6c
Modified Files
--------------
doc/src/sgml/catalogs.sgml | 7 +
doc/src/sgml/ref/create_aggregate.sgml | 18 ++
src/backend/catalog/pg_aggregate.c | 2 +
src/backend/commands/aggregatecmds.c | 4 +
src/backend/commands/define.c | 24 +++
src/backend/optimizer/util/clauses.c | 40 ++--
src/bin/pg_dump/pg_dump.c | 36 +++-
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_aggregate.h | 250 ++++++++++++------------
src/include/commands/defrem.h | 1 +
src/test/regress/expected/create_aggregate.out | 2 +-
src/test/regress/expected/opr_sanity.out | 2 +-
src/test/regress/sql/create_aggregate.sql | 2 +-
src/test/regress/sql/opr_sanity.sql | 2 +-
14 files changed, 245 insertions(+), 147 deletions(-)
