From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The Axe list |
Date: | 2008-10-11 14:02:55 |
Message-ID: | 20081011140255.GB4452@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> > CREATE AGGREGATE array_accum (anyelement)
> >
> > CREATE OR REPLACE FUNCTION array_enum(anyarray)
>
> Have you actually tried these functions on large data sets? They're not in the
> same performance league as intagg. Your array_accum is O(n^2)!
array_accum itself may also end up in core, if I have my dithers. It
makes psql's job to display column-level privs in a nice way alot
easier, and there's been quite a few cases where I've used it outside of
that, along with others. It'd be nice to have there.
That said, once it's in, we really need to rework it to not suck(tm). I
wrote a patch to do just that quite some time ago, but it required some
things in core that were ugly to expose to any aggregation function (as
I recall). If we made that only available to built-in's, then we might
be able to have array_accum in core *and* have it be fast. :)
It's a goal anyway.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-10-11 14:07:31 | Re: The Axe list |
Previous Message | Magnus Hagander | 2008-10-11 14:01:57 | Re: libpq ssl -> clear fallback looses error messages |