On Sat, 20 Oct 2001 12:48:36 -0500
Eric <[EMAIL PROTECTED]> wrote:
I wouldn't be opposed to implementing this as a part of the join
optimizer in MySQL, in fact, I've been reading through it for a few
days now... However, it seems like it would be a large project as the
join optimizer does not t
Well, I would definitely have to do the count for each query; not
because my table sizes are changing (although they are at a fairly
rapid rate), but because the number of rows I want to select is vastly
different between queries. This is actually a self-join (refer to
first emails from me to thi
Eric writes:
> I have no problem using STRAIGHT_JOIN, etc. My problem is really just
> figuring out the optimal join order. Is doing a "SELECT COUNT" on
> each of the tables I'm going to join the way to do it? Isn't there
> potential for the count to take as long as the full query processing
>
The information I require is the number of rows that will come from a
SELECT which places a certain range restriction on an unindexed
attribute...and I need this to not take much time relative to actually
executing the query (constant time would be best).
eric.
On Sat, Oct 20, 2001 at 03:06:58PM
I have no problem using STRAIGHT_JOIN, etc. My problem is really just
figuring out the optimal join order. Is doing a "SELECT COUNT" on
each of the tables I'm going to join the way to do it? Isn't there
potential for the count to take as long as the full query processing
would take (especially
Eric writes:
> Well, answering my own email, what I thought was a bug is not one at
> all. I was mistaken in thinking that MySQL paid any attention to the
> WHERE conditions when optimizing the join order beyond determining
> which keys are used for the join, correct?
>
> This is really terrib
On Fri, 19 Oct 2001 13:03:02 -0500
Eric <[EMAIL PROTECTED]> wrote:
> Well, answering my own email, what I thought was a bug is not one at
> all. I was mistaken in thinking that MySQL paid any attention to the
> WHERE conditions when optimizing the join order beyond determining
> which keys are
Well, answering my own email, what I thought was a bug is not one at
all. I was mistaken in thinking that MySQL paid any attention to the
WHERE conditions when optimizing the join order beyond determining
which keys are used for the join, correct?
This is really terrible for queries like mine
I am sending this again as I am desperate for some help and believe
this to be a signifigant bug if it actually is one...which it seems to
be. See below for examples.
What is quite puzzling is MySQL's estimation of the number of rows
from each of the self-joins. The conditions on alias queryTab
