Re: an aggregate array function

From: Joe Conway <mail(at)joeconway(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: an aggregate array function
Date: 2003-07-28 23:10:47
Message-ID: 3F25AD77.1070405@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure wrote:
> Dear hackers,
>
> Do you think there would be any use for an aggregate which returns an
> array of the aggregated (usually simple) type? Has this already been
> done by anyone? I looked at the source and noticed that for each
> inserted item, the array utility functions perform a deep copy of the
> entire array (plus a reallocation). Normally, this is no big deal, but
> if executed in the query stage, it could be kind of slow.

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.

There is a contrib (intagg) that avoids the deep copy by passing
pointers as integers, but I don't think that would be accepted as a
builtin solution. I've considered maybe using a hash table to register
valid pointers, but have not thought too hard about it yet. In any case
it won't happen 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.

> I also noticed that null values inside is an item on the todo list. Is anybody
> currently working on this?
>

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

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Gearon 2003-07-28 23:14:26 Re: RPMs for 7.3.4, and a change.
Previous Message Bruce Momjian 2003-07-28 23:09:30 Re: Regression test failure date.