Re: an aggregate array function

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Joe Conway" <mail(at)joeconway(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: an aggregate array function
Date: 2003-07-29 12:17:44
Message-ID: 303E00EBDD07B943924382E153890E5434A9AF@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway wrote:
> > Do you think there would be any use for an aggregate which returns
an
> > array of the aggregated (usually simple) type?

>What exactly have you looked at? In current cvs there is array_append
>and array_cat. There *was* array_accum, but that was yanked due to an
>objection that it was redundant with the other two.

Actually, I was looking at array_set, which has a provision to grow a 1d
array. I was looking at the 7.3.2 sources, so it's pretty clear I would
have to look at something newer. I'll wait for 7.4.

>BTW, I tried array_accum() (which is not really much different than
>array_append()) with groups of about 10,000 elements and feeding the
>array into a plr final function for a mean calculation. It was for sure

>slow compared to a native AVG() aggregate, but it wasn't that bad
>either. I don't remember the specifics, but it would be easy enough to
>try it out for yourself.

Well, if dynamic growth is expected, there are some easy optimizations
that could reduce the time spent reallocating the array. If there was a
detectable difference vs. the avg() function, which performs zero
reallocations, its probably worthwhile.

Based on what I saw with the older source, I assumed there was little or
no dynamic growth in normal use.

> No one is currently working on it that I'm aware of, but I was
> considering working on it for 7.5

By all means! What do you think about the other question about an
'array creating aggregate', is that a useful contribution?

Joe

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-07-29 12:20:18 Re: Passing server_encoding to the client is not future-proof
Previous Message Andreas Jung 2003-07-29 11:21:45 Re: concurrent writes