On Thu, Jan 16, 2014 at 3:47 PM, Florian Pflug <f...@phlo.org> wrote:
> BTW, as it stands, the patch currently uses the inverse transition > function only when *all* the aggregates belonging to one window clause > provide one. After working with the code a bit, I think that a bit of > reshuffling would allow that distinction to be made on a per-aggregate > basis. The question is, is it worth it? > > I didn't think it was all that worth it due to the fact that we'd still need to process every tuple in the frame's scope for each aggregate which has no inverse transition function, of course, there would be slightly less work to do in such cases. I guess I just assumed that work load types that would benefit from inverse transitions would have many rows instead of many aggregates and few rows. I guess to implement the aggregated up to marker variables would just need to be per aggregate rather than per window. If you think it would be worth it I can modify the patch to work that way. Regards David Rowley > best regards, > Florian Pflug >
