On Fri, Sep 24, 2010 at 1:35 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Sep 24, 2010 at 12:17 PM, Kevin Grittner >> <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
