avg(int2) and avg(int8) micro-opt

From: Neil Conway <neilc(at)samurai(dot)com>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: avg(int2) and avg(int8) micro-opt
Date: 2005-04-04 11:19:24
Message-ID: 425122BC.5030800@samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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

Attachment Content-Type Size
avg_agg_perf-1.patch text/x-patch 2.9 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-04-04 14:17:40 Re: Bug in DROP NOT NULL
Previous Message Neil Conway 2005-04-04 10:16:00 DELETE ... USING