Gleb:
Aha. OK, we tried using OPTIMIZE instead of ANALYZE, and that does
indeed update the Cardinality of the index, the way you would expect.
Thanks very much for figuring this out! I really appreciate the help.
Thanks again!
Allan
Gleb Paharenko [EMAIL PROTECTED] wrote in message
Hello.
I've checked this and found that ANALYZE table really doesn't work, but
OPTIMIZE table made its work. In case it won't help you send to list
complete definitions of you tables and queries.
Allan Miller wrote:
Hi Gleb,
Thanks for the quick response. Unfortunately, ANALYZE
In MySQL 4.1.11, if you create two temporary tables with non-unique indices as
part of the CREATE TEMPORARY TABLE statement, then
insert several hundred (or thousand) rows, a subsequent SELECT using a JOIN
between the two tables is substantially slower than if
you create the indices after
Hello.
Why is it that adding an index before or after the addition of data
makes a difference on SELECT performance?
Check whether the problem still exists if you run ANALYZE table after
inserts in case you have already created indexes. FORCE_INDEX in the
SELECT clause should help as
Hi Gleb,
Thanks for the quick response. Unfortunately, ANALYZE TABLE does not
appear to affect the Cardinality field of a temporary table (it is
still NULL, even with rows added). Only by creating the index itself
after the insert seems to make the query faster. I also tried FORCE
INDEX and it
