Re: SET autocommit begins transaction?

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