Re: Switching to InnoDB turns out dissapointing

2005-03-03 Thread Philippe Poelvoorde
Brent Baisley wrote: calculations from your query, like replace datesub(now(), interval 12 month) with a constant. Which means figuring out the right date before hand. AFAIK, no column is involved in this particular function, so there's no point doing the computation beforehand, it's done by

Re: Switching to InnoDB turns out dissapointing

2005-03-02 Thread Alfredo Cole
El Mar 01 Mar 2005 18:29, Heikki Tuuri escribi: Alfredo, I have changed my my.cnf to try and include the suggestions from the list, as much as possible and try to run my program again. It now reads like this: innodb_data_file_path = ibdata1:2G;ibdata2:2G:autoextend set-variable =

Re: Switching to InnoDB turns out dissapointing

2005-03-02 Thread Brent Baisley
Coming in late on this thread. The testing on your laptop, are you just running the one query or are you somehow emulating the typical load you are trying to design for? As you said, you are trying to improve concurrency, so you'll need to compare MyISAM and InnoDB setups under load (i.e. the

Re: Switching to InnoDB turns out dissapointing

2005-03-02 Thread Alfredo Cole
El Mié 02 Mar 2005 11:41, Brent Baisley escribió: Coming in late on this thread. The testing on your laptop, are you just running the one query or are you somehow emulating the typical load you are trying to design for? As you said, you are trying to improve concurrency, so you'll need to

Re: Switching to InnoDB turns out dissapointing

2005-03-02 Thread Brent Baisley
H, sounds like you are trying to mix OLTP and OLAP in one database structure. That's a tough one. You want your tables designed to always accept data in real time, but once the data is in, it doesn't change and you want to query it. Relational vs. Dimensional data models. Your hardware is

Re: Switching to InnoDB turns out dissapointing

2005-03-02 Thread Alfredo Cole
El Mié 02 Mar 2005 16:04, escribió: H, sounds like you are trying to mix OLTP and OLAP in one database structure. That's a tough one. You want your tables designed to always accept data in real time, but once the data is in, it doesn't change and you want to query it. Relational vs.

Switching to InnoDB turns out dissapointing

2005-03-01 Thread Alfredo Cole
Hi: I have switched from MyISAM tables to InnoDB, using MySQL 4.1.10 under SuSE 8.2. My application, an ERP system developed in-house, uses 70 tables, the largest one holding a little over one million rows. To assist when changing table structures, we developed a software that creates a new

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Gary Richardson
What have you actually done to 'tune' the server? How are you doing the inserts? InnoDB uses transactions. If you are doing each row as a single transaction (the default), it would probably take a lot longer. I assume you're doing your copying as a INSERT INTO $new_table SELECT * FROM

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Scott Klarenbach
Gary's got another point about the transactions. I'd still look to using mysqldump first if possible, if they have the ability it will be remarkably faster. Otherwise, turning transactions off before the insert, and locking the table as well, (if you haven't already done that) could prove to

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Alfredo Cole
El Mar 01 Mar 2005 17:32, Gary Richardson escribió: What have you actually done to 'tune' the server? How are you doing the inserts? InnoDB uses transactions. If you are doing each row as a single transaction (the default), it would probably take a lot longer. I assume you're doing your

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Gary Richardson
InnoDB is a very different platform from MyISAM. innodb_data_file_path = ibdata1:10M:autoextend How big is your data? You need to set your innodb_data_file_path to have enough space for this. Right now, your file is autoextending constantly. I would either turn on per table table space, or

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Heikki Tuuri
Alfredo, - Original Message - From: Alfredo Cole [EMAIL PROTECTED] Newsgroups: mailing.database.myodbc Sent: Wednesday, March 02, 2005 2:09 AM Subject: Re: Switching to InnoDB turns out dissapointing El Mar 01 Mar 2005 17:32, Gary Richardson escribi=F3: What have you actually done

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Jochem van Dieten
On Tue, 1 Mar 2005 18:09:37 -0600, Alfredo Cole wrote: El Mar 01 Mar 2005 17:32, Gary Richardson escribió: InnoDB uses transactions. If you are doing each row as a single transaction (the default), it would probably take a lot longer. I assume you're doing your copying as a INSERT INTO

RE: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Jon Frisby
set-variable =innodb_log_buffer_size=32M The log buffer is too big. Is there a performance penalty associated with making the log buffer size too large, or is just not beneficial? -JF -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:

Re: Switching to InnoDB turns out dissapointing

2005-03-01 Thread Heikki Tuuri
Jon, - Original Message - From: Jon Frisby [EMAIL PROTECTED] Newsgroups: mailing.database.myodbc Sent: Wednesday, March 02, 2005 3:32 AM Subject: RE: Switching to InnoDB turns out dissapointing set-variable =3Dinnodb_log_buffer_size=3D32M =20 The log buffer is too big