On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus <j...@agliodbs.com> wrote: > As you can probably tell, we are not ready to end the commitfest. (I > think Robert gave me this CF to show why even talking about a one-week > mini-fest is a fantasy. If so, successful.).
Heh, heh. Well, it wasn't that premeditated, but I'm always glad to reach a meeting of the minds. :-) > These are complex and need review by advanced hackers. They are also > often interdependant. As such, I'd like to automatically move his > patches to the next CF and ask that hackers who are engaged in working > on them continue to do so between CFs. There are only two patches left and I think we really ought to try to take a crack at doing something with them. Yeb is working on the userspace access vector cache patch, which I think is going drag on longer than we want keep the CommitFest open, but I'm OK with giving it a day or two to shake out. Aside from the benefit of reviewing the actual patch, I see that Yeb is pushing on KaiGai to do further work on the documentation, which I think is of great value. I will review the other patch - on shared object labels - RSN. > PATCHES WHICH I MOVED TO THE NEXT CF 9-2011: > > * Collect frequency statistics and selectivity estimation for arrays > * Allow multiple Postgres clusters running on the same machine to > distinguish themselves in the event log > * lazy vxid locks I'm not clear on your criteria for moving these patches, as they seem to be in somewhat different states. The first one is WIP, and it doesn't really matter whether you move it to the next CommitFest or just mark it returned with feedback. There is active development work going on there, so it's not going to get committed at this point. But the other two are basically just things we didn't get around to reviewing. With respect to the lazy vxid lock patch, it looks to me like Jeff has done a bit of review, and I think the real question here is whether or not we want to go ahead and make that change (with some stylistic and cosmetic corrections) or wait until we have a more complex solution to the spinlock contention problems mapped out. On a pgbench run with 8 clients on a 32-core machine, I see about a 2% speedup from that patch on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but still just a 32-core box), the results bounce around more, but taking the median of three five-minute runs, it's an 11% improvement. To me, that's enough to make it worth applying, especially considering that what is 11% on today's master is, in raw TPS, equivalent to maybe 30% of yesterday's master (prior to the fast relation lock patch being applied). More, it seems pretty clear that this is the conceptually right thing to do, even if it's going to require some work elsewhere to file down all the rough edges thus exposed. If someone objects to that, then OK, we should talk about that: but so far I don't think anyone has expressed strong opposition: in which case I'd like to fix it up and get it in. With respect to the event-log patch, MauMau has resubmitted that to the next CommitFest, so that's fine as far as it goes. But it might make sense to see if we can twist Magnus's arm into re-reviewing it now while it's fresh in his mind, rather than waiting another two or three months. > PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW: > > * Cascade Replication No update. > PATCHES STILL UNDER ACTIVE DISCUSSION: > > * Add ability to constrain backend temporary file space Now committed, by Tom. > PATCHES I CAN'T FIGURE OUT THE STATUS OF: > > * pg_comments system view I reviewed this and marked it Returned with Feedback. > * Bugfix for XPATH() if expression returns a scalar value No update. > So, down to a fairly limited list, except that we need a lot of committing. We're down to three patches that fall into this category: two XML patches by Florian, which have been somewhat derailed by an argument about whether values of type xml should, in fact, be required to be valid xml (I think you know my vote on this one...); and an error-reporting patch that Tom weighed in on over the weekend. This last suffers from the issue that it's not quite clear whether Tom is going to do the work or whether he's expecting the submitter to do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
