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>, Kevin Grittner <kgrittn(at)ymail(dot)com>, 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-16 06:39:07 |
Message-ID: | CAApHDvpqeqVZ42nbDspUGFA7M3XxC6pqMJiE5rHqZ3zqaHJ=Vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 16, 2014 at 3:47 PM, Florian Pflug <fgp(at)phlo(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-01-16 07:02:20 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Previous Message | Craig Ringer | 2014-01-16 05:54:47 | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |