In article <[EMAIL PROTECTED]>, Ken Gieselman <[EMAIL PROTECTED]> writes:
> The second issue is query performance. It seems that regardless of > what fields are selected, it reads the entire row? Since a monthly > table averages 840GB, this takes a while, even on a well-organized > query like 'Select c1 from raddata_2004_10 where granID between > 147568 and 150000' (granID tracks the granules from the start of the > mission, and is a calculated value based on the date/time of the > data in the file -- incrementing over time. The 2500 granules in > the example above represent about 1/3 of a month -- 10 days or so). > Even making sure it's using the index to do the query (which it does > anyhow, for the above query, according to explain), the current > behavior makes it reads 29548800 complete rows, which is 275.4 GB of > data to read, even though the desired return is about 1/2500th of > that (112.7 MB). Is there a kind of access pattern? Do you access c1 often in conjunction with (e.g.) c2 and c3, but hardly ever with c4 or c5? If so, you might use vertical partitioning in addition to the horizontal partitioning you're currently doing. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
