postgres/perl, autocommit and BEGIN; COMMIT;

[cbbrowne-HInyCGIudOg at public.gmane.org]

> Madison Kelly wrote:
> > Hi all,
> > 
> >   I was playing more with trying to get the database performance up when 
> > I realised that I needed to "COMMIT" to aply the updates. Realising this 
> > I decided to turn postgres' 'autocommit' back off and instead use 
> > "BEGIN/COMMIT" only on the large SELECT/INPUT/UPDATE section. The 
> > problem though is that no matter what I seem to try perl throws an empty 
> > error (generic software error) whenever this call is made 
> > ($db->do("BEGIN") || die "$DBI::errstr";).
> > 
> >   If I go directly into postgres and issue the same command it works 
> > fine. I've looked at the O'Reilley "Programming the Perl DBI" book and 
> > it has stuff on autocommit but it either doesn't say what I am supposed 
> > to do or I am too daft/tired to get it. Has anyone run into this before? 
> > Since turning autocommit back off my test submit of ~2,400 entires has 
> > gone up from ~21 seconds to ~99 seconds... That is a frustrating 
> > development, too say the least.
> 
> Are you sure that you need PostgreSQL for your project?  MySQL is faster 
> and more simple.  It's the best choise for simple databases like yours 
> (I suppose that backup database is simple).

MySQL(tm) is only free software if you're going to be distributing your
application that uses it also as free software; otherwise, it costs you
$450 USD per system, for something that is definitely more primitive
than anything else that you'd be likely to pay $450 for.

And it is anything but simple to figure out what features actually work.
<http://sql-info.de/mysql/gotchas.html>

 "It's not a bug - it's a gotcha. A "gotcha" is a feature or function
 which works as advertised - but not as expected.

 When working with the MySQL(tm) database server I have repeatedly
 encountered situations where the results of various actions have been
 unexpected and/or contrary to the behaviour generally expected of an
 SQL relational database."

In many cases, it'll silently turn your data into crud on you instead of
raising exceptions.  So I agree that it's "more simple," if we consider
that to be that it makes it "more simple" to corrupt the contents of
your database.

By the way, which properly-tuned benchmark did you base the "faster"
categorization on?  PostgreSQL used to be slow, back in the 7.0 days,
but that was back in the last millennium...
--
"cbbrowne","@","acm.org"
http://www.ntlug.org/~cbbrowne/linuxxian.html
I always try tpo do things in chronological order. 
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml