Re: Performance gain from reduction of GROUP BY memory

Alvaro Herrera wrote:
> On Tue, Aug 30, 2005 at 10:23:49AM -0400, Bruce Momjian wrote:
> 
> > > > 2005-03-12 15:25  tgl
> > > > 
> > > >     * contrib/intagg/int_aggregate.c,
> > > >     contrib/intagg/int_aggregate.sql.in, doc/src/sgml/xaggr.sgml,
> > > >     doc/src/sgml/xfunc.sgml, src/backend/executor/nodeAgg.c,
> > > >     src/backend/utils/adt/int8.c: Adjust the API for aggregate function
> > > >     calls so that a C-coded function can tell whether it is being used
> > > >     as an aggregate or not.  This allows such a function to avoid
> > > >     re-pallocing a pass-by-reference transition value; normally it
> > > >     would be unsafe for a function to scribble on an input, but in the
> > > >     aggregate case it's safe to reuse the old transition value.  Make
> > > >     int8inc() do this.  This gets a useful improvement in the speed of
> > > >     COUNT(*), at least on narrow tables (it seems to be swamped by I/O
> > > >     when the table rows are wide).    Per a discussion in early December
> > > >     with Neil Conway.  I also fixed int_aggregate.c to check this,
> > > >     thereby turning it into something approaching a supportable
> > > >     technique instead of being a crude hack.
> > 
> > I don't usually document internal API changes in the release notes. 
> > Should I?
> 
> Doesn't this potentially affect user-defined aggregates?

I read it as something that _could_ be used by user-defined aggregates,
but not something that would require a changes to a user-defined
aggregate.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073