Baron Schwartz wrote:
Chris Hemmings wrote:
Chris Hemmings wrote:
Baron Schwartz wrote:
Hi Chris,
Chris Hemmings wrote:
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this
time) since
all the values are the same. You may alread
The results of an EXPLAIN have a lot to do with the data which is
actually on the system. In this case, it seems to hinge on the
distribution of your 'price' attribute.. how many records on your
system? and what is the general distribution of the price attribute?
(how many distinct values)
On
Chris Hemmings wrote:
Chris Hemmings wrote:
Baron Schwartz wrote:
Hi Chris,
Chris Hemmings wrote:
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this
time) since
all the values are the same. You may already know that, but
thoug
Chris Hemmings wrote:
Baron Schwartz wrote:
Hi Chris,
Chris Hemmings wrote:
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this time)
since
all the values are the same. You may already know that, but thought
I'd
mention it.
Se
Baron Schwartz wrote:
Hi Chris,
Chris Hemmings wrote:
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this time)
since
all the values are the same. You may already know that, but thought I'd
mention it.
Second, my theory on why q
Hi Chris,
Chris Hemmings wrote:
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this time)
since
all the values are the same. You may already know that, but thought I'd
mention it.
Second, my theory on why query #1 is faster - if
Dan Buettner wrote:
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this time) since
all the values are the same. You may already know that, but thought I'd
mention it.
Second, my theory on why query #1 is faster - if all your prices range from
1 up, and
Chris, a couple of thoughts -
First, your index on the section is doing you no good (at this time) since
all the values are the same. You may already know that, but thought I'd
mention it.
Second, my theory on why query #1 is faster - if all your prices range from
1 up, and you're querying for p
Jeremy Cole wrote:
Hi Chris,
Chris Hemmings wrote:
Hello,
I have a table, currently holding 128,978 rows... In this table, I
have a section column (int) and a price column (int). Every row has
a section of 1 currently, every row has a price, ranging from 1 to
10,000.
I have an index on
Hi Chris,
Chris Hemmings wrote:
Hello,
I have a table, currently holding 128,978 rows... In this table, I have a
section column (int) and a price column (int). Every row has a section of 1
currently, every row has a price, ranging from 1 to 10,000.
I have an index on both columns separate
Hello,
I have a table, currently holding 128,978 rows... In this table, I have a
section column (int) and a price column (int). Every row has a section of 1
currently, every row has a price, ranging from 1 to 10,000.
I have an index on both columns separately.
Have a look at these two querie
> > 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
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
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.
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
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
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
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
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
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
MySQL <[EMAIL PROTECTED]>
> Subject: 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.
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
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
* 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
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.
This is very unacceptable, but Im just not sure what I can do to remedy
this. Here is what the query loo
If you are repeatedly querying tables on non-key fields you can improve query speeds
by implementing indexes on those fields...
For instance, if you had a personnel table with the following fields: id, lastname,
firstname, etc Where id was an auto-increment,primary key you could index the
Hi,
I have some huge databases generated from text file of a dictionary.
I would like to know if I make a query based on a field which was not metion as a
key
at the creation of the table. Is the speed of the query affected by the size of the
records and by the number of fields a rec
27 matches
Mail list logo
