From: | Ali Akbar <the(dot)apaan(at)gmail(dot)com> |
---|---|
To: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "pivot aggregation" with a patched intarray |
Date: | 2014-06-06 01:44:29 |
Message-ID: | CACQjQLq39HZ-0LqPrusW+i8Oghg3aN4tm-8i0GYs6HYerY1vvQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-06-05 17:18 GMT+07:00 Marc Mamin <M(dot)Mamin(at)intershop(dot)de>:
> I'm thinking about adding a final function to my aggregate that would replace zero values will nulls,
> hence transforming the intarray into a standard int[], possibly with nullbitmap and a lowerbound that can be > 1.
> This will probably degrade the performance considerably, but may reduce the size of the end result for spare data and not too small integers...
> Performances should greatly depend on the data distribution and order as they influence the number of palloc.
> My first tests shown as well better and poorer results.
>
> My target is not to get better performances at the first place, but to get a pivot structure in an early aggregation stage.
Usually for pivot, i use crosstab function from tablefunc
(http://www.postgresql.org/docs/9.4/static/tablefunc.html#AEN158550)
If your patch doesn't perform better, it's more easier to just use
crosstab. For storing it efficiently, the result can be transformed
into array manually.
PS: as Michael Paquier said above, its better if you could send the
patch in the .patch file format (see:
https://wiki.postgresql.org/wiki/Working_with_GIT)
--
Ali Akbar
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2014-06-06 01:57:44 | Re: tests for client programs |
Previous Message | Noah Misch | 2014-06-06 01:42:08 | Re: Allowing join removals for more join types |