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 |
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 |