On Thu, Sep 4, 2008 at 10:38 AM, mos <[EMAIL PROTECTED]> wrote
Jim,
The problem is likely your index is not defined properly. Use an "Explain"
in front of the query to see if it can use just one index from each table.
I would try building a compound index on
Products: (RecordReference, FeedId)
Jim,
I've re-posted your message to the list so others can join in the
fray. :)
Mike
At 10:50 AM 9/4/2008, you wrote:
Hi Mike,
I do believe we have done the indexing properly. Please advise if we can
make any adjustments. Here is the output from the explain statements;
16634be.png
>-Original Message-
>From: Brent Baisley [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, September 03, 2008 5:35 PM
>To: Jim Leavitt
>Cc: mysql@lists.mysql.com
>Subject: Re: Large Query Question.
>
>That's a lot of data to return, make sure you factor in data loa
It's highly unlikely hardware upgrades are needed unless you're on a really
underpowered machine. How similar are the queries on the other machines?
The "limit" clause won't reduce the time taken to do the join and grouping,
it will only reduce the amount of output.
Also, I assumeyou have indexes
At 02:49 PM 9/3/2008, Jim Leavitt wrote:
Hi Mike,
Yes sometimes, the application is an online book selection tool with
about 1 million titles in it. Now the queries which return 100,000 rows
would be something like returning all titles from a given publisher. Most
of the common searches are
On Wed, Sep 3, 2008 at 1:05 PM, Jim Leavitt <[EMAIL PROTECTED]> wrote:
>
> We are having trouble with certain queries which are returning anywhere
> from 10 - 30 rows. Total query time is taking approx 1 - 2 mins
> depending on load. Is there anything in our conf file which could improve
@lists.mysql.com
Subject: Re: Large Query Question.
That's a lot of data to return, make sure you factor in data load and
transfer time. You may try breaking your query into smaller parts and
recombining the results in a scripting language. If you are searching
on a range (i.e. date range), brea
That's a lot of data to return, make sure you factor in data load and
transfer time. You may try breaking your query into smaller parts and
recombining the results in a scripting language. If you are searching
on a range (i.e. date range), break the range into smaller parts and
run multiple queries
What are the queries? Are they straight forward selects or joins? Are the
columns you select from indexed and are the indexes up-to-date?
On Wed, Sep 3, 2008 at 12:05 PM, Jim Leavitt <[EMAIL PROTECTED]> wrote:
> Greetings List,
>
> We have a medium-large size database application which we are t
Jim,
Retrieving 100,000 rows will always take some time. Do you really
need to return that many rows? Are you selecting just the columns you need?
What are the slow queries?
Mike
At 12:05 PM 9/3/2008, Jim Leavitt wrote:
Greetings List,
We have a medium-large size database application
10 matches
Mail list logo
