Getting execute time

How do I get the time it took a sql statement to execute?

Re: INSTALLING MYSQL 5.0 ON LINUX DEBIAN 2.8

2005/12/22, John Galatti [EMAIL PROTECTED]: All I am trying to build the mysql 5.0 from the source When I run the configure scripts it error out saying it can not find termcap data base also, can not find tegenent in any library I am running under debian linux 2.8 you mean Debian with a

MySQL 5.1.4-alpha has been released

Hi, MySQL 5.1.4-alpha, a new version of the popular Open Source Database Management System, has been released. The Community Edition is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ and mirror sites. Note that

Re: Getting execute time

Hello. How do I get the time it took a sql statement to execute? mysql command line client reports the time of the query. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___

Strange behavior with integer unsigned type...

I noticed rather interesting thing... If you deduct 1 from the 0 which is stored in integer unsigned field, you get 2^32, not 0. I think that's how things are not working with version 4, and want to ask is this behavior bug or feature in mysql version 5, and is it customizable? Greetings,

Re: Do I need to tweak my server variables for this SELECT statement?

Thanks Hank. I'll try to split up the query into 2 separate queries. I think that the reason the original query is so slow is that I don't have enough RAM allocated to mysql. When the original query takes place, I see a process Copying to tmp table on disk. I believe it's writing all

Re: Joins on tables with funky data?

Just an update on this one... I changed the encryption method for the strings being stored to a method that doesn't use funky characters. I then removed the fields with the previous funky data and those weird id issues have gone away. :-) Jenifer - Original Message - From:

Is this a MySQL 5.0.x bug OR What am I missing?

I have 2 almost identical SQL statements {copied except 1 is a LEFT join and the other is an INNER join}. The INNER join gives me values for all of the fields. The LEFT join gives me NULL's for all of the prec_... {the LEFT join table} fields. If the INNER JOIN gives me values and not an empty

Re: Getting execute time

[EMAIL PROTECTED] wrote on 12/20/2005 10:29:22 AM: How do I get the time it took a sql statement to execute? You have to keep track of it client-side. I don't think the server tracks that information for you. Use whatever time-keeping function are available in your programming environment.

Re: Do I need to tweak my server variables for this SELECT statement?

The reason I suggested that you just use the alternative my-huge.cnf file is because that is a ready-prepared config file optimised for systems with lots of RAM for MySQL to use. You don't need to know which variable to change - it's already done for you. You may want/need to tweak stuff later,

Re: Do I need to tweak my server variables for this SELECT statement?

Thanks James. I'll definately give that a try. My test server has 1 gig of ram. In the my-huge.cnf example it says that it's mainly for servers that have mysql as the main process. On my production server, I have 1 gig of ram, but it also runs apache, mutliple webstites, mysql, DNS, ftp

Re: Strange behavior with integer unsigned type...

Hello. On both 4.1.16 and 5.0.17 I've got the same results, however not 2^32, but 18446744073709551615. 4.0 is deprecated and its results could be different. Please provide exact SQL statement which you're using if you still think that MySQL behaves weirdly with unsigned integers. In the

Re: Do I need to tweak my server variables for this SELECT statement?

Based on the size (and # of colums) of your result set, I'm not sure any amount of RAM would allow 360,000 records to be stored and sorted entirely in memory. After some point, mysql just decideds to use a temp table. That's the limit of my tweaking skills, so someone else is going to have to

Re: Strange behavior with integer unsigned type...

I don't think that this behaviour is very surprising. If you carry out a mathmaticical operation that returns a result outside the data type's range then it _must_ give you an incorrect result. The only alternative would be to throw an error. I know that the manual documents that after an

Re: merge table: speed benefits?

Tom Cunningham writes: (a) The docs say that spreading the underlying tables across different disks can make queries faster. I don't quite understand how this will work in a normal query: if I do a SUM(amount) over the entire table, will it be quicker if the table is spread across different disks?