From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "Eng" <eng(at)intranet(dot)greenplum(dot)com> |
Subject: | Re: [PATCHES] Avg performance for int8/numeric |
Date: | 2006-11-25 03:50:53 |
Message-ID: | C18CFD9D.E792%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Mark,
On 11/24/06 6:03 PM, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> wrote:
>> Luke Lonergan wrote:
>>> So, if I understand this correctly, we're calling Alloc and
>>> ContextAlloc 10
>>> times for every row being summed?
>
> I haven't (so profile as attached is ok)...
>
OK - so, without having looked at the source recently, the last time I
profiled it within gdb it looked like the following is what happens in the
executor agg path:
temp heaptuple is allocated, page is pinned, tuple is copied into temp
heaptuple, page is unpinned, temp heaptuple is processed in agg path
This seems to fit the pattern we're seeing in your profile given that we've
got 4 attributes in this relation except that we're seeing it happen twice.
It seems like for each attribute a DATUM is alloc'ed, plus one more, and
this is done twice -> 10 alloc calls for each row being summed.
If this is the case, we can surely not alloc/free for every row and datum by
reusing the space...
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-11-25 03:57:45 | Re: [PATCHES] Avg performance for int8/numeric |
Previous Message | Mark Kirkwood | 2006-11-25 02:16:39 | Re: [PATCHES] Avg performance for int8/numeric |
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-11-25 03:57:45 | Re: [PATCHES] Avg performance for int8/numeric |
Previous Message | Mark Kirkwood | 2006-11-25 02:16:39 | Re: [PATCHES] Avg performance for int8/numeric |