Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 24, 2010 at 12:17 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Thoughts?
>
> Premature optimization is the root of all evil. I'm not convinced
> that we should tinker with any of this before committing it and
> getting some real-world experience. It's not going to be perfect
> in the first version, just like any other major feature.
In terms of pure optimization, I totally agree -- that's why I'm
submitting early without a number of potential optimizations. I
think we're better off getting a solid base and then attempting to
prove the merits of each optimization separately. The point Heikki
is on about, however, gets into user-facing behavior issues. The
current implementation will give users an "out of shared memory"
error if they attempt to start a SERIALIZABLE transaction when our
preallocated shared memory for tracking such transactions reaches
its limit. A fairly easy alternative would be to kill running
SERIALIZABLE transactions, starting with the oldest, until a new
request can proceed. The question is whether either of these is
acceptable behavior for an initial implementation, or whether
something fancier is needed up front.
Personally, I'd be fine with "out of shared memory" for an excess of
SERIALIZABLE transactions for now, and leave refinement for later --
I just want to be clear that there is user-visible behavior involved
here.
-Kevin