> > 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.
> > 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
--
Sean Chittenden