On Wed, Nov 10, 2004 at 12:02:35AM -0500, Christopher Browne wrote:
> For instance, one of the big problems we encountered with eRServer was
> in its use of memory. The "snapshot" notion it uses tends to lead to
> fairly spectacular RAM consumption. Had it gotten more design effort,
> earlier on, perhaps it could have been more modest in memory usage.
Actually, to be fair to the original designers, that was precisely
one of their objections; but they were over-ruled by someone who
ought to have known better, but had a fixation with Java. The folks
actually responsible for the mistake in the design did not, of
course, end up continuing work on it; but the damage was already
done.
Indeed, one of the really valuable things I learned from my
experiences with erserver was that it is even harder to revisit
version 1's poor decisions in version 2 than I'd previously believed.
It's interesting that sometimes people argue in the mainline
PostgreSQL project that getting something which delivers most of what
poeple want is better than doing nothing; and yet those arguments
often don't win, unless they come with a plan of how the "real" goal
will be achieved. Tablespaces is a good example: there were a lot of
half-way proposals floating about, but until someone showed up with
plans that at least indicated the path to full-blown support, nothing
really happened. I think this is a great strength of the project,
and my experience with erserver (not to mention Marc's recent comment
that they're finding the requirements for erserver a little onerous,
so they're fixing it) is an example of the reason why.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
