aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_utilcmd.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-11-04 11:25:56 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-11-04 11:25:56 -0500
commitf21636e5d5b8394ed076e18ddc5f4ba710c69c99 (patch)
tree4940bc380da996857fc4a95e2e9d43006d6d7677 /src/backend/parser/parse_utilcmd.c
parent113d3591b859fb8dc191bc0599d1ad62d91f1aa4 (diff)
downloadpostgresql-f21636e5d5b8394ed076e18ddc5f4ba710c69c99.tar.gz
postgresql-f21636e5d5b8394ed076e18ddc5f4ba710c69c99.zip
Remove useless entries for aggregate functions from fmgrtab.c.
Gen_fmgrtab.pl treated aggregate functions the same as other built-in functions, which is wasteful because there is no real need to have entries for them in the fmgr_builtins[] table. Suppressing those entries saves about 3KB in the compiled table on my machine; which is not a lot but it's not nothing either, considering that that table is pretty "hot". The only outside code change needed is that ExecInitWindowAgg() can't be allowed to call fmgr_info_cxt() on a plain aggregate function. But that saves a few cycles anyway. Having done that, the aggregate_dummy() function is unreferenced and might as well be dropped. Using "aggregate_dummy" as the prosrc value for an aggregate is now just a documentation convention not something that matters. There was some discussion of using NULL instead to save a few bytes in pg_proc, but we'd have to remove prosrc's BKI_FORCE_NOT_NULL marking which doesn't seem a great idea. Anyway, it's possible there's client-side code that expects to see "aggregate_dummy" there, so I'm loath to change it without a strong reason. Discussion: https://postgr.es/m/533989.1604263665@sss.pgh.pa.us
Diffstat (limited to 'src/backend/parser/parse_utilcmd.c')
0 files changed, 0 insertions, 0 deletions