From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Luke Lonergan <llonergan(at)greenplum(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] Avg performance for int8/numeric |
Date: | 2006-11-27 03:55:58 |
Message-ID: | 2164.1164599758@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> Tom Lane wrote:
>> Most of this depends on being able to have a transition state value
>> that isn't any standard SQL datatype. We've discussed that recently
>> in I-forget-what-context, and didn't find a good answer yet.
> Interesting, I didn't think of doing that - was considering creating a
> suitable SQL composite type - a bit crass I guess, but I might just try
> that out anyway and see what sort of improvement it gives (we can then
> discuss how to do it properly in the advent that it's good....).
The thing is that (a) composite types have *at least* as much overhead
as arrays, probably rather more; and (b) a composite type in itself
doesn't allow non-SQL types as components, so still doesn't let you
tackle the idea of keeping the running sum in numeric.c's internal
calculation format. So I don't think this will prove much --- the only
gain you can get is the count-in-int8-instead-of-numeric bit, which is
interesting but there is much left on the table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ehab Galal | 2006-11-27 04:32:32 | system table scan |
Previous Message | Tom Lane | 2006-11-27 03:29:46 | Re: tiny fix needed |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2006-11-27 05:22:39 | Re: [PATCHES] Avg performance for int8/numeric |
Previous Message | Mark Kirkwood | 2006-11-27 00:52:46 | Re: [PATCHES] Avg performance for int8/numeric |