We solved it here,
There was a problem in the query, we removed the "t1" at the 'group by'
section. The problem was really a sintax error in the code not in the
server.
Thanks,
Douglas
2007/7/19, Michael Dykman <[EMAIL PROTECTED]>:
instead of leaving it in PHP, please print out your fully fo
For anyone who is interested the thing that worked and brought the query
down from 8 minutes to 5 seconds was separating out the JOIN to remove the
OR. I made it into two queries and UNIONed them together and it all works
beautifully now.
Thanks.
At 02:33 PM 2/25/2004 -0800, Daniel Clark wrote
Have one more question - indexing the relevant columns based on the explain
info has made all of our queries immensely faster.
But it appears that new rows are not automatically indexed. Does anyone
know about this and if they are not indexed how do I reindex the tables?
Thanks.
--
MySQL Gen
On 26 Feb 2004 at 13:22, Eric Scuccimarra wrote:
> But it appears that new rows are not automatically indexed. Does
> anyone know about this and if they are not indexed how do I reindex
> the tables?
You're misunderstanding something. When you create an index, all the
rows in the table are inde
Eric Scuccimarra wrote:
Have one more question - indexing the relevant columns based on the
explain info has made all of our queries immensely faster.
But it appears that new rows are not automatically indexed. Does anyone
know about this and if they are not indexed how do I reindex the tables?
Tried to make the indexes separate and did an EXPLAIN and no performance
increase and this is what the explain says:
id select_type table typepossible_keys
key key_len ref rowsExtra
1 SIMPLE tb ALL PRIMARY,tb_ndx3,tb_ndx4,tb_ndx5
NULLNU
I know Oracle likes the indexes separatly, but mySQL might like combinations.
> No, we tried individual indexes and then one big grouped index but not
> individual indexes on each of the fields. Adding the index actually
> added a few seconds to the query so we weren't sure if that was the way
>
No, we tried individual indexes and then one big grouped index but not
individual indexes on each of the fields. Adding the index actually added a
few seconds to the query so we weren't sure if that was the way to go.
I'll try this, though.
Eric
At 10:36 AM 2/25/2004 -0800, Daniel Clark wrote:
On 25 Feb 2004 at 13:09, Eric Scuccimarra wrote:
> Select*
> FROM Table1 as a
> INNER JOIN Table2 as b ON (a.ID = b.ID or (a.Field1 = b.Field1 and
> a.Field2 = b.Field2)) WHERE bla bla bla
It's hard to know without seeing the indexes and the full WHERE
clause, but part of th
Do you have separate indexes on:
Table1.ID
Table2.ID
Table1.Field1
Table2.Field1
Table1.Field1
Table1.Field2
> Select*
> FROM Table1 as a
> INNER JOIN Table2 as b ON (a.ID = b.ID or (a.Field1 = b.Field1 and
> a.Field2 = b.Field2))
> WHERE bla bla bla
>
> We ha
What does the explain look like?
-Original Message-
From: Eric Scuccimarra [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 1:03 PM
To: [EMAIL PROTECTED]
Subject: Query Problems
I am doing a very simple query joining two copies of tables with identical
structures but differ
Use merge tables, or two separate queries.
"Wix,Christian XCW" wrote:
>
> Hi
> I have two similar tables. (table1 & table2). They contain the columns
> "name", "distance" and "date". Table1 is year 2000 and Table2 year 2001.
>
> I need to get the total distance for each name.
> For year 2000 I
Hi
In my opinion I would imagine Merged tables would do what you wanting. Refer
to the MYSQL manual.
Thanks
~
Warren van der Merwe
Software Director
PRT Trading (Pty) Ltd t/a RedTie
Cell (083) 262-9163
Office (031) 767-0249
> -Original Message-
> From:
Create a merge table of the year 2000 and year 2001 tables as follows.
Then run your select on the merged table.
You can then drop the merge table if you don't need it anymore.
CREATE TABLE table3 (name, distance, date) TYPE=MERGE UNION=(table1,table2);
SELECT name, SUM(distance) FROM table3 GR
14 matches
Mail list logo
