]> granicus.if.org Git - postgresql/commit
Allow aggregates to provide estimates of their transition state data size.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 16 Nov 2013 21:03:40 +0000 (16:03 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 16 Nov 2013 21:03:40 +0000 (16:03 -0500)
commit6cb86143e8e1e855255edc706bce71c6ebfd9a6c
tree2ed7cf0b5fe28b8ba858ae3e384534cdb7f31aa3
parent55c3d86a2a374f9d8fd88fd947601c1f49a4da08
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
14 files changed:
doc/src/sgml/catalogs.sgml
doc/src/sgml/ref/create_aggregate.sgml
src/backend/catalog/pg_aggregate.c
src/backend/commands/aggregatecmds.c
src/backend/commands/define.c
src/backend/optimizer/util/clauses.c
src/bin/pg_dump/pg_dump.c
src/include/catalog/catversion.h
src/include/catalog/pg_aggregate.h
src/include/commands/defrem.h
src/test/regress/expected/create_aggregate.out
src/test/regress/expected/opr_sanity.out
src/test/regress/sql/create_aggregate.sql
src/test/regress/sql/opr_sanity.sql