On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The cost to us is a few days work and the benefit is a whole year's
> worth of increased performance for our user base, which has a hardware
> equivalent well into the millions of dollars.
I doubt that this is an accurate reflection of the cost.
What was presented by Robert Haas was a "proof of concept," and he
pointed out that it had numerous problems. To requote:
"There are numerous problems with the code as it stands at this point.
It crashes if you try to use 2PC, which means the regression tests
fail; it probably does horrible things if you run out of shared
memory; pg_locks knows nothing about the new mechanism (arguably, we
could leave it that way: only locks that can't possibly be conflicting
with anything can be taken using this mechanism, but it would be nice
to fix, I think); and there are likely some other gotchas as well."
Turning this into something ready for production deployment in 9.1
would require a non-trivial amount of additional effort, and would
likely have the adverse effect of deferring the release of 9.1, as
well as of further deferring all the effects of the patches submitted
for the latest commitfest
(<https://commitfest.postgresql.org/action/commitfest_view?id=10>),
since this defers release of 9.2, as well.
While the patch is a fine one, in that it has interesting effects, it
seems like a way wiser idea to me to let it go through the 9.2
process, so that it has 6 months worth of buildfarm runs before it
gets deployed "for real" just like all the other items in the 2011-06
CommitFest.
Note that it may lead to further discoveries, so that perhaps, in the
9.2 series, we'd see further improvements due to things that are
discovered as further consequence of testing
<https://commitfest.postgresql.org/action/patch_view?id=572>.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"