From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2016-01 Commitfest |
Date: | 2016-01-25 18:57:40 |
Message-ID: | CA+Tgmoaks7HL7RXcCOy-9+c3YuSbTriU9DmcOoFRhg05-SurFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 25, 2016 at 11:36 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> We still have 41 patches that haven't gotten enough review though. The
> bad part about it is that there's a number of patches that have been
> bouncing for many commitfests now. Here's a list of the patches with
> the most such actions (both in Needs Review and Ready for Committer
> state):
>
> Five "Moved to next commitfest"
> * https://commitfest.postgresql.org/8/49/
> Default Roles
This patch has gotten some feedback relatively recently, specifically
to question whether we want it. I think it's fair to say that the
reaction to this proposal has never been cold nor more than lukewarm.
> Four "Moved to next commitfest"
> * https://commitfest.postgresql.org/8/129/
> Unique Joins
I've been hoping Tom would pick this up. If he doesn't, I will look
at it eventually, but it's not on my top 20 list of things to get
committed at this point. I think it's worthwhile, but I just don't
have the bandwidth.
> Three "Moved to next commitfest"
> * https://commitfest.postgresql.org/8/169/
> postgres_fdw: Options to set fetch_size at the server and table level.
Just reviewed that.
> * https://commitfest.postgresql.org/8/180/
> Atomic commit support for foreign data wrappers
I think this needs considerably more work, but it probably needs a
series of detailed reviews first. There's also some question about
how this fits into the distributed transaction manager work by the
Postgres Pro guys.
> * https://commitfest.postgresql.org/8/189/
> extends pgbench expressions with functions
I looked at this in the past and felt that the design was not good.
It's been revised since then, but I haven't gotten back around to look
at it again. I think this has gotten a fair amount of discussion but
I'm not sure we've converged on something really solid yet.
> * https://commitfest.postgresql.org/8/210/
> improving join estimates using FK
This thread seems to end with some author-reviewer discussion that petered out.
> * https://commitfest.postgresql.org/8/260/
> checkpoint continuous flushing
Andres FTW.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2016-01-25 18:58:20 | Re: Patch: ResourceOwner optimization for tables with many partitions |
Previous Message | Pavel Stehule | 2016-01-25 18:57:21 | Re: count_nulls(VARIADIC "any") |