On Fri, Sep 24, 2010 at 1:35 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, Sep 24, 2010 at 12:17 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.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.
Yeah, I understand, but I think the only changes we should make now
are things that we're sure are improvements. I haven't read the code,
but based on reading the thread so far, we're off into the realm of
speculating about trade-offs, and I'm not sure that's a good place for
us to be.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company