From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com> |
Subject: | Re: Combining Aggregates |
Date: | 2015-03-30 12:25:14 |
Message-ID: | CA+U5nMKmSk8ZTndqRb7q7=WwzFN15XmiF7ADoFP4yXbitO7iVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 March 2015 at 01:08, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On 18 December 2014 at 02:48, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>> David, if you can update your patch with some docs to explain the
>> behaviour, it looks complete enough to think about committing it in
>> early January, to allow other patches that depend upon it to stand a
>> chance of getting into 9.5. (It is not yet ready, but I see it could
>> be).
>>
>
> I've been thinking of bumping this patch to the June commitfest as the patch
> only exists to provide the basic infrastructure for things like parallel
> aggregation, aggregate before join, and perhaps auto updating materialised
> views.
>
> It seems unlikely that any of those things will happen for 9.5.
> Does anybody object to me moving this to June's commitfest?
If the patch is ready, it should stay in the queue.
A global decision to move all uncommitted patches to June might occur
later, but that's a different decision. I don't think we should be
prejudging that situation, all it would do is hide the extent of the
real problem with reviews.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-03-30 12:34:08 | Re: getting rid of "thread fork emulation" in pgbench? |
Previous Message | Michael Paquier | 2015-03-30 11:09:12 | Re: pgsql: Centralize definition of integer limits. |