Re: [PATCH] Negative Transition Aggregate Functions (WIP)

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(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-04-07 15:41:53
Message-ID: CAEZATCUw5Yno6TcnMQ+Qyvmxahgw3Ewczct_QkJQHxGThp5niQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7 April 2014 14:09, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> On Apr5, 2014, at 09:55 , Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>> On 5 April 2014 08:38, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>>> [snip] releasing it in this state feels a little half-baked
>>> to me.
>>>
>>
>> I regret writing that almost as soon as I sent it. The last of those
>> queries is now over 10 times faster than HEAD, which is certainly
>> worthwhile. What bugs me is that there is so much more potential in
>> this patch.
>
> Well, the perfect is the enemy of the good as they say. By all means,
> let's get rid of the O(n^2) behaviour in 9.5, but let's get a basic
> version into 9.4.
>
>> I think it's pretty close to being committable, but I fear that time
>> is running out for 9.4.
>
> I'm not aware of any open issues in the basic patch, other then
> scaling the reported calling statistics by nloops, which should be
> trivial. I'll post an updated patch later today.
>
> I don't really expect all the add-on patches to make it into 9.4 -
> they don't seem to have gotten much attention yet - but at least
> the inverse transition functions for the basic arithmetic aggregates
> should be doable I hope.
>

I've just finished reading through all the other patches, and they all
look OK to me. It's mostly straightforward stuff, so despite the size
it's hopefully all committable once the base patch goes in.

I think that you're probably right that optimising
window_gettupleslot() to eliminate the O(n^2) behaviour can be left to
a later patch --- the existing performance benefits of this patch are
enough to justify its inclusion IMO. It would be nice to include the
trivial optimisation to window_gettupleslot() that I posted upthread,
since it gives such a big improvement for only a few lines of code
changed.

If you post a new patch set, I'll mark it as ready for committer attention.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-07 16:00:49 Re: Fwd: Proposal: variant of regclass
Previous Message Robert Haas 2014-04-07 15:37:36 Re: B-Tree support function number 3 (strxfrm() optimization)