Sean Chittenden wrote:
> > > But that'd result in at least two transactions per connection because
> > > in my database class wrapper I turn autocommit off. Under any kind of
> > > load or performance situations, that's pretty unacceptable. Granted
> > > there's nothing that would need to be flushed to disk (hopefully), it
> > > still strikes me that there would have to be some locking involved and
> > > that would degrade the performance of the entire system.
> >
> > You would never see a performance hit. It doesn't dirty any buffers or
> > anything. Heck, a SET with autocommit on is already in its own
> > transaction.
>
> Alright, that's good to hear... I'd think there'd be some locking
> that'd have to take place to start/commit the transaction which
> wouldn't necessarily be tied to IO performance so much as CPU
> performance... but I'm not that knowledgable of the internals.
>
> Regardless, however, it's still a usability issue, IMHO.
Yep.
> > > I just saw Tom's post and it seems like something has to give
> > > someplace... I'm not a fan of the idea of creating the special case,
> > > don't get me wrong, but is there a reasonable alternative? -sc
> >
> > I am willing to special case autocommit because it is so tied to
> > transactions anyway.
>
> Does postgresql support subtransactions? I thought only OODBs had
> this and that relational DBs don't by and large, PostgreSQL included.
> I personally am not haphazardous with setting autocommit, but users
> who use any kind of interface are likely to screw things up and
> scratch their head wondering why. Why would this have to be in its
> own transaction? -sc
We want subtransactions but we don't have them yet.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073