Re: [PATCHES] Avg performance for int8/numeric

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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