From: | Ali Akbar <the(dot)apaan(at)gmail(dot)com> |
---|---|
To: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "pivot aggregation" with a patched intarray |
Date: | 2014-06-04 23:11:37 |
Message-ID: | CACQjQLodX_FQQULuu3_gdqpw0jZSY2_at8OhC2gVvtpp4KWksg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-06-01 20:48 GMT+07:00 Marc Mamin <M(dot)Mamin(at)intershop(dot)de>:
>
> >On Sat, May 31, 2014 at 12:31 AM, Marc Mamin <M(dot)Mamin(at)intershop(dot)de> wrote:
> >> I have patched intarray with 3 additional functions in order to count[distinct] event IDs
> >> into arrays, whereas the array position correspond to the integer values. (mimic column oriented storage)
> >
> >I didn't look at the feature itself, but here are some comments about
> >the format of the patch:
> >- Be careful the newlines on the file you posted use ¥r¥n, which is
> >purely Windows stuff... This will generate unnecessary diffs with the
> >source code
> I don't mean to suggests this directly as a patch,
> I'm first interested to see if there are some interest
> for such an aggregation type.
From what i see, the icount_to_array is complementary to standard
count() aggregates, but it produces array. If the values are not
sparse, i think the performance and memory/storage benefit you
mentioned will be true. But if the values are sparse, there will be
many 0's, how it will perform?
I'm interested to benchmark it with some use cases, to confirm the
performance benefits of it.
--
Ali Akbar
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-04 23:12:14 | Re: [BUGS] BUG #9652: inet types don't support min/max |
Previous Message | Tom Lane | 2014-06-04 23:10:16 | Re: [HACKERS] BUG #9652: inet types don't support min/max |