d). However,
by clicking on the link next to that function, you wind up at another
page that also has the answer you seek.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
pow <[EMAIL PROTECTED]> wrote on 09/07/2005 06:15:12 AM:
> Hi everyone, Im executing the fo
so executing
the query TWICE is taking its toll on the server.
Thanks!
Pow
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Hi everyone,
I have a freeform string field in one of my tables that is xml encoded.
Basically, i can create xml tags on the fly as and when i want, and just
store the entire xml string in the field.
This eliminates the need to create a new column everytime i have a new
"datatype". I can just
Hi everyone,
Take for example two identical tables A & B, and a MERGE table merging
both of them.
Would there be any performance advantage if I do a select (with a where
criteria on an indexed column) on the MERGE table, as opposed to doing a
union of two selects with the same WHERE criteria?
the key cache and the first attempt did not.
I am executing the queries directly in MYSQL command prompt.
Is there some other type of cacheing that i am missing?
Thanks!
Pow
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com
Rereading his initial query, u are right. this is not a situation of not
having the right composite index.
Yup, u are counting many rows, and hence it will take awhile.
Michael Stassen wrote:
pow wrote:
In this case, u require 2 indexes on table b.
1. WHERE b.basetype = 0 (requires
In this case, u require 2 indexes on table b.
1. WHERE b.basetype = 0 (requires index on b.basetype)
2. b.BoardID = m.BoardID (requires index on b.BoardID)
However, you are only allowed one index per table join.
Hence you need ONE composite index on table b with the fields b.basetype
and b.Boa
