Thanks for the reply Brad, two questions about your situtation:
(1) The speedup only applies because of concurrent queries, right?
With sequential queries you would expect no speedup?
(2) If you have 180 underlying tables, then each query to the merge
table has to do 180 separate index lookups, r
Tom Cunningham writes:
>(a) The docs say that spreading the underlying tables across different
>disks can make queries faster. I don't quite understand how this will
>work in a normal query: if I do a SUM(amount) over the entire table,
>will it be quicker if the table is spread across different dis
OK thanks for your help, so my summary:
(1) spreading merged tables across disks will only help concurrent
queries (in my data-warehouse application I'm doing things serially).
(2) there's no efficiency in the way a merge table splits the indexes
into smaller files -- if anything, it will be less
Hello.
> (a) The docs say that spreading the underlying tables across different
> disks can make queries faster. I don't quite understand how this will
> work in a normal query: if I do a SUM(amount) over the entire table,
> will it be quicker if the table is spread across different disks? I
Hi all.
I'm working on splitting a 5G myisam fact table into separate parts,
and putting a merge table on top.
his will definitely help with table management, but I am hoping that a
merge table might help me with query speed:
(a) The docs say that spreading the underlying tables across different
