| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
| Date: | 2014-01-10 08:34:55 |
| Message-ID: | CAApHDvpXMXM8d3ufteuWfc7+0Rt_O1D3-NsU8Zs8jMDjdvVLmg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> bool_or()
> FALSE can be removed, removing TRUE requires a rescan. Could be made
> fully invertible by counting the number of TRUE and FALSE values,
> similar to my suggestion for how to handle NaN for sum(numeric).
> Same works for bool_and().
>
> bit_or()
> Like boo_or(), 0 can be removed, everything else requires a rescan.
> Same works for bit_and()
>
>
Interesting, I'd not thought of any way to optimise these ones, but I had
originally thought about allowing the inverse transition functions to
report if they could perform the inverse transition based on the value they
received and if they reported failure, then perform the rescan.
I just don't quite know yet the base way for the inverse transition
function to communicate this to the caller yet. If you have any ideas on
the best way to do this then I'd really like to hear them.
Regards
David Rowley
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Tiikkaja | 2014-01-10 09:36:43 | Re: array_length(anyarray) |
| Previous Message | David Rowley | 2014-01-10 08:26:52 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |