Re: IN vs. OR on performance

2009-03-30 Thread Baron Schwartz
On Sun, Mar 29, 2009 at 10:19 AM, Claudio Nanni claudio.na...@gmail.com wrote: An explain of the two statements yields the same plan, anybody knows if they are actually translated in the same plan? There is a difference. The IN list is sorted so lookups can be done as a binary search. A bunch

Re: IN vs. OR on performance

2009-03-29 Thread Ian P. Christian
2009/3/29 Oscar ro4...@gmail.com: Hi all- I want to know what the difference between IN and OR is under the hood. select * from dummy_table where id in (2, 3, 4, 5, 6, 7); select * from dummy_table where id=2 or id=3 or id=4 or id=5 or id=6 or id=7; I've have thought once the query is

RE: IN vs. OR on performance

2009-03-29 Thread Martin Gainty
. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Date: Sun, 29 Mar 2009 09:13:10 + Subject: Re: IN vs. OR on performance From: poo

Re: IN vs. OR on performance

2009-03-29 Thread Claudio Nanni
An explain of the two statements yields the same plan, anybody knows if they are actually translated in the same plan? Claudio Ian P. Christian wrote: 2009/3/29 Oscar ro4...@gmail.com: Hi all- I want to know what the difference between IN and OR is under the hood. select * from

Re: 5.0.1 vs 5.0.15: view performance

2005-10-31 Thread Jeremiah Gowdy
see your table using the indexes to perform the query. - Original Message - From: YL [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: mysql@lists.mysql.com Sent: Sunday, October 30, 2005 11:16 PM Subject: Re: 5.0.1 vs 5.0.15: view performance Thanks a lot Shawn: After adding index, it's

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread SGreen
YL [EMAIL PROTECTED] wrote on 10/30/2005 10:24:24 AM: Dear list, I need some inputs/help on my finding below: 5.0.15 make my view (below) almost useless compare with 5.0.1-alpha: with the same data set, 5.0.15 took 18min but 5.0.1 took 6.3sec to get the result: mysqlselect count(1) from

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread Paul DuBois
At 15:53 -0500 10/30/05, [EMAIL PROTECTED] wrote: YL [EMAIL PROTECTED] wrote on 10/30/2005 10:24:24 AM: Dear list, I need some inputs/help on my finding below: 5.0.15 make my view (below) almost useless compare with 5.0.1-alpha: with the same data set, 5.0.15 took 18min but 5.0.1 took

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread YL
| ++-+---+--+---+--+-+--+--+-+ 3 rows in set (0.11 sec) mysql - Original Message - From: [EMAIL PROTECTED] To: YL [EMAIL PROTECTED] Cc: mysql@lists.mysql.com Sent: Sunday, October 30, 2005 1:53 PM Subject: Re: 5.0.1 vs 5.0.15: view performance YL [EMAIL PROTECTED] wrote on 10/30/2005 10:24:24 AM

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread SGreen
: mysql@lists.mysql.com Sent: Sunday, October 30, 2005 1:53 PM Subject: Re: 5.0.1 vs 5.0.15: view performance YL [EMAIL PROTECTED] wrote on 10/30/2005 10:24:24 AM: Dear list, I need some inputs/help on my finding below: 5.0.15 make my view (below) almost useless compare with 5.0.1

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread YL
Thanks Shawn for the help: The same query took 2min less than before on 5.0.15 after using inner join. Is what you ask: mysql show create table address\G; *** 1. row *** Table: address Create Table: CREATE TABLE `address` ( `city`

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread SGreen
As I suspected, you have no indexes. You didn't even define a primary key (PK). For each table, decide which column or combination of columns you can use to uniquely identify each row. Make that your PRIMARY KEY for each table. For other columns or combinations of columns you frequently use in

Re: 5.0.1 vs 5.0.15: view performance

2005-10-30 Thread YL
) unsigned NOT NULL default '0', . PRIMARY KEY (`unit_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 Thanks again - Original Message - From: [EMAIL PROTECTED] To: YL Cc: mysql@lists.mysql.com Sent: Sunday, October 30, 2005 9:25 PM Subject: Re: 5.0.1 vs 5.0.15: view performance

Re: Merge vs multiple innodb performance

2005-02-09 Thread SGreen
Marcin Lewandowski [EMAIL PROTECTED] wrote on 02/08/2005 05:29:39 PM: Chuck Herrick napisa(a): 200 - 400 tables is too many. Is it too many for merge, innodb or both? Try having one CUSTOMERS table. You know who is logged in, so you can use that information in a WHERE clause. Yes,

Re: Merge vs multiple innodb performance

2005-02-08 Thread Marcin Lewandowski
Chuck Herrick napisa(a): 200 - 400 tables is too many. Is it too many for merge, innodb or both? Try having one CUSTOMERS table. You know who is logged in, so you can use that information in a WHERE clause. Yes, but If somebody would find a password (maybe using brute-force attack) to one

Re: MySQL vs MS-SQL performance

2001-03-27 Thread Jeremy D . Zawodny
On Tue, Mar 27, 2001 at 02:12:36PM -0800, Steve Quezadas wrote: Anyways, a period of time elapsed and we decided to move to MS-SQL server for feature reasons, and when we had the MS-SQL ODBC driver point to the newly created MS-SQL server (roughly same specs), it was like 50% faster! What

RE: MySQL vs MS-SQL performance

2001-03-27 Thread Oson, Chris M.
: Tuesday, March 27, 2001 4:18 PM To: [EMAIL PROTECTED]; Steve Quezadas Subject: Re: MySQL vs MS-SQL performance Steve, I also experienced the same results you did until I realized that the MS-SQL connection was using pooled connections and my use of MySQL wasn't. After I started using persistent