Just a quick note to add to this conversation:
Pete Harlan wrote:
On Fri, Sep 14, 2007 at 01:33:51AM -0700, Jeremy Cole wrote:
MySQL's optimizer cannot reorder the joins because it has the potential
to change the result of the query.
Not in all cases. If a LEFT JOIN query also has a WHERE cl
On Fri, Sep 14, 2007 at 01:33:51AM -0700, Jeremy Cole wrote:
> Hi Shawn, Lucio,
>
> >SELECT STRAIGHT_JOIN
> >FROM ...
> >LEFT JOIN ...
> >WHERE ...
> >...
>
> Just to correct a point here... if a query uses only LEFT JOIN or RIGHT
> JOIN, the join order is fixed by the query's order itself,
On Fri, 14 Sep 2007, Jeremy Cole wrote:
> Just to correct a point here... if a query uses only LEFT JOIN or RIGHT JOIN,
> the join order is fixed by the query's order itself, so using STRAIGHT_JOIN
> should have no effect whatsoever. Equally important, since the join order is
but experimentally
Hi Shawn, Lucio,
SELECT STRAIGHT_JOIN
FROM ...
LEFT JOIN ...
WHERE ...
...
Just to correct a point here... if a query uses only LEFT JOIN or RIGHT
JOIN, the join order is fixed by the query's order itself, so using
STRAIGHT_JOIN should have no effect whatsoever. Equally important,
sin
On Tue, 4 Sep 2007, Shawn Green wrote:
> > On Tue, 4 Sep 2007, Lucio Chiappetti wrote:
> > For each I tested 3 cases (total 16*3=48) :
> >
> > a) the query on the "virtual" table correlated with the external
> > (the virtual is my G left join t1 ... left join tn). [...]
> > represents my REFERENC
Lucio Chiappetti wrote:
On Tue, 4 Sep 2007, Lucio Chiappetti wrote:
I'll do some experimenting and report back.
In lack of better ways of doing a tie-break, I've done the following
tests (with the linemode client), checking both the results of a query and
the total time spent. I tested 16 d
On Tue, 4 Sep 2007, Lucio Chiappetti wrote:
> I'll do some experimenting and report back.
In lack of better ways of doing a tie-break, I've done the following
tests (with the linemode client), checking both the results of a query and
the total time spent. I tested 16 different combinations of a
On Mon, 3 Sep 2007, Shawn Green wrote:
> What I hope to do is to help you to make you queries work better by
> applying hints, modifiers, and limits to the optimizer.
Many thanks, Shawn.
> "STRAIGHT_JOIN is identical to JOIN, except ...
>
> You asked what would happen if you replaced all of yo
Hello Lucio,
Thank you for the excellent description of you problem. I believe I
completely understand both the data you are handling and the problems
you are facing.
I would not ask you to change your schema at this point. There is far
too much work put into it at this phase to suggest a re
As I'm new on this list and can't find a "policy statement", I assume it
is OK to reply to the list in "discussion list" fashion. If instead it is
preferred to reply to each sender privately and later I'd post a summary,
please let me know and I'll comply.
On Sat, 1 Sep 2007, Shawn Green wrote:
Hello Lucio,
(reply below)
Lucio Chiappetti wrote:
I have some queries, involving a largish number of JOIN, which
are apparently very slow or even take forever (a mysqladmin processlist
shows them remain in the "statistics" status for a long time, in most
cases I have to kill them after severa
I have some queries, involving a largish number of JOIN, which
are apparently very slow or even take forever (a mysqladmin processlist
shows them remain in the "statistics" status for a long time, in most
cases I have to kill them after several minutes).
When I first had the problem I googled a
12 matches
Mail list logo