thanks jeremy for the reply Jeremy Zawodny wrote: > > > > > > any idea why is it that the mysqld daemon is not using the CPUs and/or > > why is this taking so long?? > > You might benefit from a larger key buffer. > > Can you show us the output of "vmstat 1" for 10 or 20 seconds? >
What would be an appropriate key_buffer_size. other 'typical' operations I would need to perform are joins of say 15-20 tables each about 1,000,000 rows or so. of course the plan is to index all the join columns. the end result of the joins should be the same size as an individual table. i.e. for each row of first table there should be only one matching row of the second and so on. should the key_buffer_size be roughly the size of all the index files of these tables combined? more importantly, does such a query even sound feasible (this database is not built yet, I am trying to plan ahead). It seems that poor performance related to my earlier question was due to disk io delays after all. IRIX has a 'sar' command that probably does the same thing as vmstat. here is the output (half way through the index building: the 50% idle is due to the second processer. 00:22:13 %usr %sys %intr %wio %idle %sbrk %wfs %wswp %wphy %wgsw %wfif 00:22:18 15 3 0 33 48 0 99 0 0 1 0 00:22:23 9 2 0 41 49 0 100 0 0 0 0 00:22:28 11 2 0 38 50 0 100 0 0 0 0 00:22:33 14 2 0 34 49 0 100 0 0 0 0 00:22:38 16 2 0 32 49 0 100 0 0 0 0 00:22:43 22 4 0 25 48 0 100 0 0 0 0 00:22:48 16 3 0 33 49 0 100 0 0 0 0 00:22:53 7 1 1 42 48 0 100 0 0 0 0 00:22:58 1 1 1 48 49 0 100 0 0 0 0 00:23:03 5 2 0 44 48 0 100 0 0 0 0 Average 12 2 0 37 49 0 100 0 0 0 0 thanks again Murad --------------------------------------------------------------------- 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