This patch changes int2_avg_accum() and int4_avg_accum() use the nodeAgg
performance hack Tom introduced recently. This means we can avoid
copying the transition array for each input tuple if these functions are
invoked as aggregate transition functions.

To test the performance improvement, I created a 1 million row table
with a single int4 column. Without the patch, SELECT avg(col) FROM table
took about 4.2 seconds (after the data was cached); with the patch, it
took about 3.2 seconds. Naturally, the performance improvement for a
less trivial query (or a table with wider rows) would be relatively smaller.

It is possible that the transition array might be TOAST'ed (not that I'd
expect that to occur in practice, of course). The aggregates should
continue to work in this case: PG_DETOAST_DATUM() is equivalent to
PG_DETOAST_DATUM_COPY() if the datum is toast'ed, so in effect we just
won't implement the nodeAgg performance hack if the transition array is
toasted. If I've mucked this up, let me know.

Barring any objections, I'll commit this tomorrow.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Neil Conway <neilc@samurai.com> writes:
> This patch changes int2_avg_accum() and int4_avg_accum() use the nodeAgg
> performance hack Tom introduced recently.

Why only those two? Might as well make all the accum functions look alike.

> It is possible that the transition array might be TOAST'ed (not that I'd
> expect that to occur in practice, of course).

AFAICS that is impossible, since the transition value is never stored to
disk. But your analysis is good anyway.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Tom Lane wrote:
> Why only those two? Might as well make all the accum functions look alike.

Yeah, there might be some others we could improve. float4_accum() and
float8_accum() look like they could be improved pretty easily, and
do_numeric_accum() should also be fixable with some hackery. I suppose
it's also worth optimizing int2_sum(), int4_sum() and int8_sum(). I'll
send a patch for this later today or tomorrow. Are there any other
transition functions where we can apply this technique?

BTW, int2_avg_accum() and int4_avg_accum() patch applied to HEAD.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> Why only those two? Might as well make all the accum functions look alike.

> Yeah, there might be some others we could improve. float4_accum() and
> float8_accum() look like they could be improved pretty easily, and
> do_numeric_accum() should also be fixable with some hackery. I suppose
> it's also worth optimizing int2_sum(), int4_sum() and int8_sum(). I'll
> send a patch for this later today or tomorrow. Are there any other
> transition functions where we can apply this technique?

Actually, do_numeric_accum can't be fixed easily because numeric is a
varlena type. The basic requirement for this hack is that the size of
the transition value be constant ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Neil Conway wrote:
> Yeah, there might be some others we could improve. float4_accum() and
> float8_accum() look like they could be improved pretty easily, and
> do_numeric_accum() should also be fixable with some hackery. I suppose
> it's also worth optimizing int2_sum(), int4_sum() and int8_sum().

Attached is a patch that applies the same optimization to int2_sum(),
int4_sum(), float4_accum(), and float8_accum(). It wasn't possible to
optimize do_numeric_accum() or int8_sum() since they both use numerics.
Performance gains are similar to those measured when this optimization
has been applied to similar aggregates (e.g. avg(float8) goes from about
6400 ms to about 4300 ms on my machine, for a single column of float8
and about 1 million rows).

Barring any objections, I'll apply this to HEAD tomorrow.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil Conway wrote:
> Attached is a patch that applies the same optimization to int2_sum(),
> int4_sum(), float4_accum(), and float8_accum(). It wasn't possible to
> optimize do_numeric_accum() or int8_sum() since they both use numerics.

Applied.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match