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 this list a few days ago), so I can't just count how many rows are in each table, because there is only one. The problem is that each self-join in my query has widely varying number of rows it returns based on what range I specify for the nvalue column.
So I'm not really sure what to do...Wouldn't doing a COUNT on each self-join involved table take almost as much time as running the query on each table? 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 take WHERE conditions on the joins into account at all when estimating number of rows coming from a table. In addition, I would probably need to start storing some more metadata in order to facillitate the kind of optimization I need... has anyone thought about doing this? eric. On Sat, Oct 20, 2001 at 07:52:28PM +0300, Sinisa Milivojevic wrote: > 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 > > would take (especially since the attribute I'm doing a range on is not > > indexed)? > > > > eric. > > > > -- > > _____ _ > > | ____|(_) http://ir.iit.edu/~ej > > | _| | | Page me via ICQ at > > | |___ | | http://wwp.mirabilis.com/19022931 > > |______/ | or by mailing [EMAIL PROTECTED] > > |__/ > > > > Well , first of all this is recommandation only until we further > improve the optimiser. > > In most applications relative sizes of tables do not change > drastically. It is extremely rare that a tabla A that has 1000 times > less rows then table B would in short time have 1000 times more rows > then table B. > > > -- > Regards, > __ ___ ___ ____ __ > / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> > / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer > /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus > <___/ www.mysql.com > -- _____ _ | ____|(_) http://ir.iit.edu/~ej | _| | | Page me via ICQ at | |___ | | http://wwp.mirabilis.com/19022931 |______/ | or by mailing [EMAIL PROTECTED] |__/ --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
