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)-
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().
Att
Neil Conway <[EMAIL PROTECTED]> 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
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 suppo
Neil Conway <[EMAIL PROTECTED]> 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
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 c