From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nodeAgg perf tweak |
Date: | 2004-12-03 02:19:26 |
Message-ID: | 1102040366.22124.244.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2004-12-02 at 20:51 -0500, Tom Lane wrote:
> No. The current code involves two pallocs per cycle, one inside the
> aggregate function to construct its result value, and then one in
> datumCopy to copy the result into the proper context.
Ah, true -- missed the fact that PG_RETURN_INT64() does a palloc(). (We
really ought to fix that on 64-bit machines...)
> The fact that it's a central fix for all aggregate functions is
> definitely a nice feature of your approach, but I am concerned about the
> possible side-effects on user-defined aggregate functions that may not
> work as you expect them to. I think it's safer to keep the aggregate
> code behaving as-is and get the performance win in the individual
> functions. There are not that many aggregates that we really care that
> much about.
Okay, fair enough :)
BTW, the spec you posted in your previous message makes sense to me.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-12-03 02:20:37 | Re: lwlocks and starvation |
Previous Message | Bruce Momjian | 2004-12-03 01:59:06 | Re: Code documentation |