Re: Commitfest Status: Sudden Death Overtime - Mailing list pgsql-hackers

On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus <josh@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