postgres/perl, autocommit and BEGIN; COMMIT;

Ilya Palagin ilyapalagin-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org
Mon May 31 00:39:13 UTC 2004


cbbrowne-HInyCGIudOg at public.gmane.org wrote:
>>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.

One has to buy license if he distributes any part of MySQL
along with his product (this is what they call MySQL-based product), which
doesn't comply with GPL.   See
http://www.mysql.com/products/licensing/commercial-license.html
Isn't it fair?

If a product just uses MySQL as a third-party application, there is no need
to buy a license.

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

I've never had such an experience.  Servers crashed due to faulty memory
or hard drives, power was lost, applications occupied completely system
resources, but the only thing to be done to MySQL database after that
was myisamchk.

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

Well, it's an image.  MySQL has been considered the fastest one (don't 
forget
about absence of referential integrity, stored procedures, subqueries). 
  Maybe
situation has changed since 4.1 version was released, not sure.
--
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





More information about the Legacy mailing list