Re: Speed Up Query

> > AND Substring(a.mob, 1, 4) = b.mob_series > There's what is probably the major problem with your query: your join condition. Indices (you *do* have them on your join fields, don't you ?) only work on the entire field you've indexed. Function indices are not supported in MySQL, so you'll

Re: Speed Up Query

using Execution plan: ++++-+---++-+---+-+- ---+ | id | select_type| table | type| possible_keys | key| key

Re: Speed up slow SQL statement.

You may see the section named group by optimization on the document. On Tue, Sep 30, 2008 at 4:44 AM, Rob Wultsch <[EMAIL PROTECTED]> wrote: > Glancing over things I suggest: > ALTER TABLE browse_nodes_to_products ADD INDEX(browse_node_id,product_id); > > (if product_id has greater cardinality pu

Re: Speed up slow SQL statement.

Glancing over things I suggest: ALTER TABLE browse_nodes_to_products ADD INDEX(browse_node_id,product_id); (if product_id has greater cardinality put that before browse_node_id) The syntax: inner join (browse_nodes, browse_nodes_to_products) on (browse_nodes.amazon_id = browse_nodes_to_products

Re: Speed up slow SQL statement.

Good morning everyone, products.id is defined as a PRIMARY KEY so it's index. browse_nodes_to_products.product_id is defined as a INDEX so it's indexed. browse_nodes_to_products.browse_node_id is defined as an INDEX so it's indexed. browse_nodes.amazon_id is defined as an INDEX so it's index

RE: Speed up slow SQL statement.

Hi Eric- the immediate challenge is to fic the join statement so make sure products.id is indexed make sure browse_nodes_to_products.product_id is indexed make sure browse_nodes_to_products.browse_node_id is indexed make sure browse_nodes.amazon_id is indexed there seems to be mapping/relations

Re: Speed of queries in a MySQL database

At 09:21 AM 3/4/2007, Jonathan Trahair wrote: Hi Everyone. I have just upgraded a Visual Basic 6 project which used an Access database as a data back end, using DAO and SQL strings. The Access database was exceedingly slow, and prone to glitches. I have changed the VB code to ADO, and set up

Re: Speed of queries in a MySQL database

Jonathan Trahair wrote: Hi Everyone. I have just upgraded a Visual Basic 6 project which used an Access database as a data back end, using DAO and SQL strings. The Access database was exceedingly slow, and prone to glitches. I have changed the VB code to ADO, and set up a MySQL database in th

RE: Speed of DECIMAL

Sent: Friday, October 27, 2006 2:10 AM > To: 'Jerry Schwartz'; mysql@lists.mysql.com > Subject: RE: Speed of DECIMAL > > > From: Jerry Schwartz [mailto:[EMAIL PROTECTED] > > > > What is going slower, INSERT / UPDATES or SELECTS? > > Complex SELECTs > >

Re: Re: Speed of DECIMAL

I'll second what Chris said, which is that all the joined columns should be of the same type for speed. Also, your substring and LIKE comparisons are going to be problematic, as those are string operations, not numeric, and MySQL is having to convert all the decimal values to strings before compa

Re: Speed of DECIMAL

[EMAIL PROTECTED] wrote: From: Jerry Schwartz [mailto:[EMAIL PROTECTED] What is going slower, INSERT / UPDATES or SELECTS? Complex SELECTs CHAR should make for quite efficient processing, since to a large degree nobody cares what's in there: it just slams the data in, or does a simple byte

RE: Speed of DECIMAL

> From: Jerry Schwartz [mailto:[EMAIL PROTECTED] > > What is going slower, INSERT / UPDATES or SELECTS? Complex SELECTs > CHAR should make for quite efficient processing, since to a > large degree nobody cares what's in there: it just slams the > data in, or does a simple byte-by-byte compari

RE: Speed of DECIMAL

What is going slower, INSERT / UPDATES or SELECTS? CHAR should make for quite efficient processing, since to a large degree nobody cares what's in there: it just slams the data in, or does a simple byte-by-byte comparison. There is probably hardware support for that kind of operation. Decimal arit

Re: Speed of DECIMAL

Did you leave your queries searching on ASCII instead of decimal? Depending on how you structured your queries, MySQL may actually be converting the fields to ASCII in order to do the comparison. Which would probably take 3x longer since it's not using an index. - Original Message - Fro

Re: speed up index creation on existing tables?

Sounds like a very nice idea to me, but this could be a problem if temp tables need to be bigger than RAM+Swap, which could easily be the case in a table with 100,000,000 rows. Gabriel PREDA schrieb: For this table this is to late... leave it running... If you want to do this on another table

Re: speed up index creation on existing tables?

For this table this is to late... leave it running... If you want to do this on another table(s)... and in general on huge loaded MySQL servers I recomend the following... Create a directory let's say /mnt/mem_fs Mount in it /dev/shm use "tmpfs" as filesystem... Now you have a directory that sto

Re: speed of 3.23 vs 4.1 for logging server

The RPM's from mysql.com should work fine on FC3. The source RPMs should build as well. I would say it shouldn't take that much effort. I don't know about performance issues, but I always figured that you can tune InnoDB with a bit more control than myisam. For inserts, you could probably have a l

Re: Speed of Inserts into MyIsam tables from mysqlbinlog

Since playing back binary logs is just like doing normal queries the tips on this page mostly apply. http://dev.mysql.com/doc/mysql/en/insert-speed.html Depending on your shell scripting level you might have to mysqlbinlog to a file then add in lock statments or whatever you decide to use. -Eric

Re: Speed up SELECT DISTINCT

| Extra | +-+ 438710 | Using index | +-+ - Original Message - From: "Michael Stassen" <[EMAIL PROTECTED]> To: "Jim McAtee" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 16, 2004 10:03 PM

Re: Speed up SELECT DISTINCT

It is difficult to say without knowing more. It would be helpful if you'd show us the queries, as well as what EXPLAIN has to say about them. Your table structure may also help. I will say that most queries I've seen posted here which used DISTI

RE: speed issue - inserts slowing down selects

Daniel, also consider selecting as high priority. That will cause select queries to jump ahead of pending insert queries. That will allow each select to only have to wait for at most one insert to complete. Cheers, -Dana -Original Message- From: Daniel Cummings [mailto:[EMAIL PROTECTED

Re: speed issue - inserts slowing down selects

One thing you could do, which may not be the best, is insert one (or some set limit) of rows at a time, then after each sleep for .25 seconds or something, so that your inserts get spread out more over time, and there is idle time between them for the selecting clients to complete. Obviously this m

Re: Speed this up?

Alex Pilson wrote: I have this query below than seems to be running really slow. I have tried indexing key JOIN fields but it seems to have not helped. Any pointers would be greatly appreciated. (ver: MySQL 3.23.53) side note: seems to run fairly quick in 4.0.18 SELECT dl.email as download_email

Re: Speed differences between joins and subqueries?

On 04.06.2004 20:46 (+0200), Sasha Pachev wrote: Subquery optimizer is still is a very early stage in 4.1. Much more often than not, a carefully crafted join, union, or a sequence of queries using a temporary table will be faster. In fact, I wonder if it is even possible to write a machine subqu

Re: Speed differences between joins and subqueries?

Daniel Ek wrote: Hi all, I am wondering if anyone have any knowledge if there is speed difference between joins (inner | outer | left | right) and subqueries. Would I actually gain preformance using subqueries (new since 4.1) against using the "old" joins? Would be interesting to hear comments

Re: Speed Problem

Mustafa Yalcin Acikyildiz wrote: hello. i have a speed problem ;). table: title_id bigint(50),title char(200), cdate datetime query: select title, max(cdate) as mdt, count(title_id) as num from entry where (date_format(cdate, '%Y-%m-%d %H:%i:%s') The function in whre clause forces a full table

Re: Speed Problem

> table: > title_id bigint(50),title char(200), cdate datetime > > query: > select title, max(cdate) as mdt, count(title_id) as > num > from entry > where (date_format(cdate, '%Y-%m-%d %H:%i:%s') > between '2004-05-07 00:00:01' AND '2004-05-08 > 23:59:59') > and > (on = 'Y') > group by title > ord

Re: Speed Problem

> i have a speed problem ;). > > table: > title_id bigint(50),title char(200), cdate datetime Next time, please provide information about existing indices and provide output of EXPLAIN of the query... > query: > select title, max(cdate) as mdt, count(title_id) as num > from entry > where (date_f

Re: Speed of MyISAM vs. InnoDB

Simon Green wrote: Is it just not the case that InnoDB table have to do more as they have more functionality and so take more time? Not exactly. InnoDB does indeed support transactions, uses the ultimate in concurrency control (multiversioning) and provides foreign key constraints. That said

Re: Speed of MyISAM vs. InnoDB

Is it just not the case that InnoDB table have to do more as they have more functionality and so take more time? Simon - Original Message - From: "Jiří Matějka" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 18, 2004 10:38 AM Subject: Speed of MyISAM vs. InnoDB >

Re: Speed of MyISAM vs. InnoDB

"Jiri Matejka" <[EMAIL PROTECTED]> wrote: > Now I found one more "strange" thing - if I use show tables to get table > properties, then if table is MyISAM the number of rows is correct and if it > is InnoDB number of rows is around 2000 lower... And the innodb table looks > 8 times bigger than myis

Re: Speed of MyISAM vs. InnoDB

From: "Jiri Matejka" <[EMAIL PROTECTED]> > Now I found one more "strange" thing - if I use show tables to get table > properties, then if table is MyISAM the number of rows is correct and if it > is InnoDB number of rows is around 2000 lower... And the innodb table looks > 8 times bigger than myisa

Re: Speed of MyISAM vs. InnoDB

Now I found one more "strange" thing - if I use show tables to get table properties, then if table is MyISAM the number of rows is correct and if it is InnoDB number of rows is around 2000 lower... And the innodb table looks 8 times bigger than myisam table (field data_length in show table status q

Re: Speed of MyISAM vs. InnoDB

Unfortunately it persists also for real queries. Eg. query like "select field1 from table1 where field3=xx" and InnoDB is cca 10times slower than MyISAM. I wonder whether there is not some error or problem in my.ini settings, I use following settings: innodb_additional_mem_pool_size 1048576 innodb

Re: Speed of MyISAM vs. InnoDB

COUNT(*) is a special case for MyISAM. However, you'll find that anything that has a WHERE clause that takes advantage of an index is pretty quick for both MyISAM and InnoDB tables. For instance: SELECT COUNT(*) FROM table; Is slow as all buggery on InnoDB, but: SELECT COUNT(id) FROM table WH

Re: Speed of MyISAM vs. InnoDB

I think count(*) is a special case: MyISAM holds a record count which it can access instantly, InnoDB has to count rows. Does the time difference persist for real queries? Alec Jiří Matějka <[EMAIL PROTECTED]> wrote on 18/02/2004 10:38:13: > Hi all, > I'm using mysql 4.0.17 and I ha

Re: Speed difference between boolean full-text searches and full-text searches

Hi! Sorry for delayed answer - I was on vacations... On Dec 08, Uros Kotnik wrote: > OK, I will give you more details. > > Table CDS, have 1,053,794 rows, FT index on title, > Data 67,646 KB, Index 70,401 KB > > Table ARTISTS, Rows 292,330, FT on name, > Data 8,096 KB > Index 17,218 KB > > T

RE: Speed difference between boolean full-text searches and full-text searches

x' ) AND MATCH ( cds.title ) AGAINST ( '2001' ) Regards -Original Message- From: Chuck Gadd [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 21:50 To: Uros Kotnik; [EMAIL PROTECTED] Subject: Re: Speed difference between boolean full-text searches and full-text

RE: Speed difference between boolean full-text searches and full-text searches

MATCH (cds.title) AGAINST ('+music +mix +2001' IN BOOLEAN MODE) and artists.artistid = cds.artistid AND artists.artistid = tracks.artistid AND cds.cdid = tracks.cdid -Original Message- From: Chuck Gadd [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 21:50 To:

Re: Speed difference between boolean full-text searches and full-text searches

Uros Kotnik wrote: It makes sense, but Sergei G. said : "And are you sure the numbers are correct, the first query - the one without "IN BOOLEAN MODE" - is faster ? I would expect the opposite." I guess that for my DB I can't expect satisfied "in boolena mode" times ? But also when searching wit

RE: Speed difference between boolean full-text searches and full-text searches

ld be satisfied with 0.5 - 1 sec. times -Original Message- From: Chuck Gadd [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 13:17 To: Uros Kotnik; [EMAIL PROTECTED] Subject: Re: Speed difference between boolean full-text searches and full-text searches Uros Kotnik wrote:

Re: Speed difference between boolean full-text searches and full-text searches

Uros Kotnik wrote: Time for first SQL : 21 sec. SELECT artists.name, cds.title, tracks.title FROM artists, cds, tracks WHERE artists.artistid = cds.artistid AND artists.artistid = tracks.artistid AND cds.cdid = tracks.cdid AND MATCH (artists.name) AGAINST ('madonna'IN BOOLEAN MODE) AND MATCH (cds

RE: Speed difference between boolean full-text searches and full-text searches

ds, tracks I get time of 1.9 sec. instead < 1 sec. ? Regards -Original Message- From: Sergei Golubchik [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 00:02 To: Uros Kotnik Cc: [EMAIL PROTECTED] Subject: Re: Speed difference between boolean full-text searches and full-text

RE: Speed difference between boolean full-text searches and full-text searches

cds, tracks I get time of 1.9 sec. instead < 1 sec. ? Regards -Original Message- From: Sergei Golubchik [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 00:02 To: Uros Kotnik Cc: [EMAIL PROTECTED] Subject: Re: Speed difference between boolean full-text searches and full-text

Re: Speed difference between boolean full-text searches and full-text searches

Hi! On Nov 27, Uros Kotnik wrote: > Executing this SQL, takes ~5 sec. > > select artists.name, cds.title, tracks.title from artists, tracks, cds > where artists.artistid = tracks.artistid and cds.cdid = tracks.cdid > and MATCH (artists.name) AGAINST ('madonna') > and MATCH (cds.title) AGAINST

Re: speed of cross-database queries

On Thu, Sep 25, 2003 at 11:46:49AM -0700, Kevin wrote: > Hello, > > I'm doing this some in my application, and was wondering if anyone had > any ideas about the efficiency of cross-database queries: > > > "Select * from db1.poems left join db2.users on poems.mid = users.mid" They're no slower t

Re: Speed Performance Question

Hi Stefan, I haven't ad experience with such a big table yet, but I would like to make a guess. Depending how you use the data (often read, often write, mixed etc.) I would suggest setting up 2 tables. If you use innodb you can distribute the two tables over several disks which should at lea

Re: Speed Up Insert Query Results

It's not the insert that are taking a long time, it's the selects. Trying running the command with and explain in front of it to see where you query is bottlenecking. Perhaps you don't have an index on one of your search fields. The first query is probably running faster because you have a few

RE: Speed Up Insert Query Results

cmt.place=y03m02_Acdt.place AND y03m02_Acmt.charge_id=y03m02_Acdt.charge_id; -Original Message- From: Keith C. Ivey [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 5:54 PM To: [EMAIL PROTECTED] Cc: Charles Vos Subject: Re: Speed Up Insert Query Results On 26 Jun 2003 at 17:45, Charles Vos w

Re: Speed Up Insert Query Results

On 26 Jun 2003 at 17:45, Charles Vos wrote: > Could somebody please enlighten me as to why it takes nearly 2 > hours to put 8 rows of data into my table? It's not the INSERT that's taking so long -- it's the SELECT. Try the SELECT alone, and it will probably take the same amount of time

RE: Speed of SELECT ... LIMIT #,#?

> -Original Message- > From: Nick Arnett [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2003 8:48 AM ... > Just noticed something odd, though, with the MySQLdb SSCursor. > When close() > is called, it does a fetchall(), getting any records that you hadn't > retrieved, trying to load

RE: Speed of SELECT ... LIMIT #,#?

> -Original Message- > From: Joseph Bueno [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2003 1:36 AM .. > If you want to speed it up, you have to make it use an index. > You need to add a WHERE or an ORDER BY clause. > Have you tried : > SELECT Message_ID, Body FROM Body_etc ORDER

Re: Speed of SELECT ... LIMIT #,#?

If you want to speed it up, you have to make it use an index. You need to add a WHERE or an ORDER BY clause. Have you tried : SELECT Message_ID, Body FROM Body_etc ORDER BY Message_ID LIMIT N,M Of course, I assume that Message_ID is indexed ;) Regards, Joseph Bueno Nick Arnett wrote: -Original

RE: Speed of SELECT ... LIMIT #,#?

> -Original Message- > From: Jeremy Zawodny [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2003 9:17 PM > Please post the query and the output of running it thru EXPLAIN. > > It is likely sorting the results without an index and having to weed > thru more and more records the farther

Re: Speed of SELECT ... LIMIT #,#?

On Mon, Mar 24, 2003 at 04:48:01PM -0800, Nick Arnett wrote: > I'm reading 1,000 records at a time from a large table (overcoming the FT > indexing problem I wrote about yesterday) and I'm discovering that as the > starting record number grows larger, the retrieve speed is dropping rapidly. > Any s

Re: Speed improvement with packet proceeding!?

It sounds like you're suggestion something like Oracle does with PL/SQL, which I think is the better way to go. Then it's really up to the user to decide how to optimize multiple steps by creating a batch of commands to be run. On Sunday, February 23, 2003, at 03:57 PM, Julian wrote: I'm not

RE: Speed improvement with packet proceeding!?

I know very LITTLE about the internal working of MySQL. So, I am not the right people to comment it. However, from my experience MySQL is quite optimized for some operation but not for all. I think Julian actual suggested a very good idea on the searching optimization for single user. At presen

RE: Speed improvement with packet proceeding!?

On 23-Feb-2003 Julian wrote: > Speed improvement with packet proceeding!? > > 1. Packet proceeding: > > I'm not quite sure is it possible with Mysql but it could be "easy" to > be implemented. > For example: > > select * from table where id=52 and name='some' > select * from table where id=23

Re: speed problems (?!)

On Wed, Sep 25, 2002 at 11:33:37PM +0300, Gergely Imre wrote: > > hi all > > i've mysql 2.32.52 installed, and there is a table with nearly 2.000.000 > records in it (4 field/record). i have 256megs of RAM, and the linux > version is RedHat 7.3. i do a simple delete, like: > > delete from foo

Re: speed problems (?!)

Any reason you can't upgrade to a newer version? mysql,query DSL - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this threa

Re: Speed problems.. Still

On Thu, 15 Aug 2002, Benjamin Pflugmann wrote: > Let me try to explain. > Last, an introduction into LEFT JOINs: Benjamin, this was a very good explanation. I would love to see an edited version of your post included in the "Tutorial" section of the very fine manual. Regards, Thomas Spah

Re: Speed problems.. Still

Hi. On Wed 2002-08-14 at 15:06:02 -0700, [EMAIL PROTECTED] wrote: > If you were here right now I would kiss you! Well not really, but I can not > believe what that did!! It takes around 2-4 seconds now for the query to > execute completely! I wish I understood when to use what type of join sin

Re: Speed problems.. Still

Hi To help improve the performance, it would help knowing - table structures, use show create table ; - how many records in each table - have all the tables being analyzed/optimized recently Inner joins whilst very useful, do impact on performance. In some cases it is more efficient to use a s

Re: Speed problems.. Still

I wrote: >> SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS >> Comp, Jobs.JobID, Employers.EmpID >> FROM Location >> INNER JOIN JobsLocation ON JobsLocation.LocID = Location.LocID >> INNER JOIN Jobs ON Jobs.JobID = JobsLocation.JobID >> INNER JOIN Employers ON Employ

Re: Speed problems.. Still

If you were here right now I would kiss you! Well not really, but I can not believe what that did!! It takes around 2-4 seconds now for the query to execute completely! I wish I understood when to use what type of join since it is very obvious to me that it matters, and matters greatly! Thank y

Re: Speed problems.. Still

On 14 Aug 2002, at 14:46, Richard Baskett wrote: > Ok that saved me 5 seconds per query! So far so good! I couldn¹t use the > STRAIGHT_JOIN though (received errors) so I made it an INNER JOIN. This is > the new query: You say the EXPLAIN output looks the same, so the 5 second savings is just r

Re: Speed problems.. Still

I am using 3.23.51 also "Dost thou love life? Then do not squander time; for that's the stuff life is made of." - Ben Franklin > From: Rahadul Kabir <[EMAIL PROTECTED]> > > what version of mysql are you running? I was having similar problem then I > upgraded my mysql to 3.23.51 and the problem

Re: Speed problems.. Still

what version of mysql are you running? I was having similar problem then I upgraded my mysql to 3.23.51 and the problem was solved. Richard Baskett wrote: > Ok Im still having some serious speed problems and obviously since more > records are being added every day the problem is getting worse.

Re: Speed problems.. Still

Ok that saved me 5 seconds per query! So far so good! I couldn¹t use the STRAIGHT_JOIN though (received errors) so I made it an INNER JOIN. This is the new query: SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS Comp, Jobs.JobID, Employers.EmpID FROM Location INNER

Re: Speed problems.. Still

On 14 Aug 2002, at 14:09, Richard Baskett wrote: > SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company AS > Comp, Jobs.JobID, Employers.EmpID > FROM Employers > INNER JOIN Jobs ON Employers.EmpID = Jobs.EmpID > INNER JOIN JobsLocation ON Jobs.JobID = JobsLocation.JobID > INN

Re: Speed !

On Saturday, 3. August 2002 06:44, Lord Loh wrote: Hi, > I have a database of mysql with 3 million records. No query is > performed in > less than 10 seconds!(With Index and all that) Some more information like your table structure, indexes and a sample query and an explain could help to give

Re: Speed issues...

> > Organization: Giant Electronic Brain > > Date: Wed, 31 Jul 2002 09:57:20 -0400 > > To: Richard Baskett <[EMAIL PROTECTED]>, MySQL <[EMAIL PROTECTED]> > > Subject: Re: Speed issues... > > > > On Wednesday 31 July 2002 05:17 am, Richard Baskett wrote: > &g

Re: Speed issues...

In the last episode (Jul 31), Richard Baskett said: > Ok I've Analyzed each table and it looks like it has cut around 20 seconds > off of the average time. > > Im trying to figure out how I can take out the left joins.. I need > some of that data to be displayed to the user.. Would it be quicker

Re: Speed issues...

n Nelson <[EMAIL PROTECTED]> > Cc: MySQL <[EMAIL PROTECTED]> > Subject: Re: Speed issues... > > Ok I've Analyzed each table and it looks like it has cut around 20 seconds off > of the average time. > > Im trying to figure out how I can take out the left joins.

Re: Speed issues...

g to cling to the patterns you know inhibits your ability to discover what you don't know." - Eric Allenbaugh > From: MySQL Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]> > Date: Wed, 31 Jul 2002 13:25:02 -0700 > To: [EMAIL PROTECTED] > Subject: Re: Speed issues... &g

Re: Speed issues...

TECTED]> > Cc: MySQL <[EMAIL PROTECTED]> > Subject: Re: Speed issues... > > In the last episode (Jul 31), Richard Baskett said: >> When they are searching sometiems they do not search for Location.. >> When that's the case I leave the location string out, if they d

Re: Speed issues...

Subject: Re: Speed issues... From: "Jared Richardson" <[EMAIL PROTECTED]> === "Richard Baskett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > This is my first post here.. So be nice! ;) > > I have a database with a little over 60,000 re

Re: Speed issues...

In the last episode (Jul 31), Richard Baskett said: > When they are searching sometiems they do not search for Location.. > When that's the case I leave the location string out, if they do not > search for Category, I leave the Category string out, but when they > do.. That's the query I get.. The

Re: Speed issues...

egory and JobsLocation first when > they're constrained with LEFT JOIN. > > -- > Dan Nelson > [EMAIL PROTECTED] > > From: Dan Nelson <[EMAIL PROTECTED]> > Date: Wed, 31 Jul 2002 13:42:41 -0500 > To: Richard Baskett <[EMAIL PROTECTED]> > Cc: Tod Harter <[E

Re: Speed issues...

In the last episode (Jul 31), Richard Baskett said: > >> SELECT DISTINCT Location.SortID AS Loc, LocName, JobTitle AS Job, Company > >> AS Comp, Jobs.JobID, Employers.EmpID > >> FROM Employers > >> LEFT JOIN Jobs USING (EmpID) > >> LEFT JOIN JobsLocation USING (JobID) > >> LEFT JOIN Location USING

Re: Speed issues...

take them out! yes? Cheers! Rick "When the solution is simple, God is answering." - Albert Einstein > From: Tod Harter <[EMAIL PROTECTED]> > Organization: Giant Electronic Brain > Date: Wed, 31 Jul 2002 09:57:20 -0400 > To: Richard Baskett <[EMAIL PROTECTED]>,

Re: Speed issues...

are there indexes on the right fields? do a "describe" on the query and let us know what you get. On Wednesday, July 31, 2002, at 02:17 AM, Richard Baskett wrote: > This is my first post here.. So be nice! ;) > > I have a database with a little over 60,000 records and when I do a > search > on

Re: Speed issues...

On Wednesday 31 July 2002 05:17 am, Richard Baskett wrote: > This is my first post here.. So be nice! ;) OK, no flames ;o). I'd want a bit more information in order to really diagnose this. The first thing I would tell you to do is to EXPLAIN this query. To do that just tack the keyword EXPLAI

Re: Speed issues...

* Richard Baskett > This is my first post here.. So be nice! ;) :) > I have a database with a little over 60,000 records and when I do a search > on that db it takes a little over a minute and a half to return results. That sounds slow, yes. > This is very unacceptable, but Im just not sure wh

RE: Speed issue

> So it may seem that on your machine, with both MySQL and Access loaded > together Access runs ever so much faster. However, you are comparing single > use Access to single use MySQL. (also, once mysql starts caching things, it > gets faster. The more you use it, the faster it runs!) Also, once y

RE: Speed issue

Simon, Several issues come to mind. First, as Tim suggested, make sure ODBC logging is turned off. It should be by default but if you turn it on, it will whip your HD like a bad puppy. Second, run MySQL on a different machine. More importantly, understand the difference between Access and MySQL

RE: Speed issue

From: Simon Ashby [mailto:[EMAIL PROTECTED]] Sent: 01 July 2002 10:58 To: MYSQL Subject: Speed issue > > Any pointers on how to get rid of the disk churning and get a normal > response in this set up would be much appreciated. Turn off OBDC logging. Tim Ward Brett Ward Limited - www.brettward.co

RE: speed optimization on awkward self join

* Colin Anderson [...] > SELECT a.name, b.value, bb.value > FROM characters a, char_data b, char_data bb, char_data_type c, > char_data_type cc > WHERE a.id = b.character_id > and a.id = bb.character_id > and (b.char_data_type_id = c.id > and b.value = '18' > and c.type = 'Strength') >

RE: Speed question.

BD [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 10:42 AM To: [EMAIL PROTECTED] Subject: Re: Speed question. At 01:17 AM 3/20/2002, you wrote: >An Oracle DB programmer reviewed a query that I wrote and told me that >putting constants at the beginning of the que

Re: Speed question.

At 01:17 AM 3/20/2002, you wrote: >An Oracle DB programmer reviewed a query that I wrote and told me that >putting constants at the beginning of the query would make it slower. I >thought I'd go to the experts on MySQL and be told the truth one way of >the other. > >Example query: > >SELECT >

Re: Speed question.

On Wed, Mar 20, 2002 at 12:17:58AM -0700, zxcv wrote: > > An Oracle DB programmer reviewed a query that I wrote and told me > that putting constants at the beginning of the query would make it > slower. I thought I'd go to the experts on MySQL and be told the > truth one way of the other. Perhap

RE: Speed difference

The boxes running the MySQL were isolated from other users so there was no activity on them while I was performing the benchmark tests. There was no tuning - I just installed the MySQL from their binary packages, that is I was using the default config files (hoping that they are the same - I w

Re: Speed difference

Nesh, > With all of the benchmark test I have used the same DB structure, same > TABLE structure, and finally same iterations. > > This probably means that Solaris I/O is really poor, or there is some other > explanation (like changing some kernel parameters to get Solaris working > well with

RE: Speed difference

: Sherzod Ruzmetov aka sherzodR [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 5 February 2002 11:14 AM To: Nesh Nenad Mijailovic Cc: '[EMAIL PROTECTED]' Subject: Re: Speed difference : after timing the program that was targeting MySQL on different platforms : the results are (clie

Re: Speed difference

: after timing the program that was targeting MySQL on different platforms : the results are (client program running always from the same box that is not : hosting MySQL): : : Windows NT - 25 sec (Intel P-III) : Linux - 27 sec (Intel P-III) : Solaris 2.7 - 1 min 40 sec (Ul

RE: Speed problem with sorted select statements

* [EMAIL PROTECTED] > Description: > I try to get the last 5 different times and the first 5 > different times. There is a difference of aproximately > 1 minute and 40 seconds between this to queries. I do not see > reason for the difference in the execution times. There is a problem in some case

RE: speed up MySQL Selections

> Hello, > > i have a question. Don't we all :-) > I will have to set up a MySQL Database which will have a hughe amount of > entries in a table. I did some tests and my select statements > would need lot > of time. > > I just wanna ask if there are some generally ways to speed up > perfo

RE: speed up MySQL Selections

Hello, Depending on what types of values are in your table, and the types of selects that you are going to perform, you will most likely notice a speed change if you were to INDEX some of your attributes...Just look up INDEX in the mysql manual... I notice the largest improvement when I INDEX on

Re: speed of mysql insert through C api

On Thu, 15 Nov 2001, Jonothan Farr wrote: > There's no way to know that without knowing the schema of the > table you're inserting into. How you index it is going to be the >biggest factor there. just a plain file with 2 columns - one of them is a decimal field - taht's all. cu, fns -[ mailto:[

Re: speed of mysql insert through C api

On Thu, 15 Nov 2001, Gabor Penoff wrote: > can you tell me an estimated speed about filling 100 records with > mysql insert by using the C api? Last insert job I ran did c. 400 inserts per second. This is real ("wall") time and some computations were involved. (Dont go running fetching a ca

  1   2   >