From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | drkp(at)csail(dot)mit(dot)edu, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Serializable Snapshot Isolation |
Date: | 2010-09-24 17:48:53 |
Message-ID: | AANLkTikydrL0P+2=aCmchwYVyVnd-b8rzOmpdsSBnoRu@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 24, 2010 at 1:35 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2010-09-24 18:36:06 | History for 8.3.6 tag is a little strange |
Previous Message | Kevin Grittner | 2010-09-24 17:35:44 | Re: Serializable Snapshot Isolation |