Hi Xiaobin,
On Mon, 2010-02-01 at 13:55 +0800, Xiaobin She wrote:
> Does "In any case, no it is not possible" means that it is not possible to
> remove the hash index on the primary key?
Correct.
> What I don't understand is that why an hash index is compulsory for the
> primary key, why can't I use an ordered index to do all the jobs? You
> mentioned that the cluster is partitioned based on the hash of the primary
> key, but while using an ordered index, the random access and range access
> can be done through the ordered index, then why can't the partition of the
> cluster be done based on an ordered index?
An ordered index is slower at equality lookups and would lead to an
uneven distribution of data, so it would not make sense to use this for
the partitioning.
> And if the data are ordered, and an hash index is used for the partition,
> then the data may not be continuous after the the partition, doesn't this
> cost much more than using an ordered index for the partition?
Ordered indexes cost more to execute queries against, yes.
> >As far as the API goes it is only one read operation, but internally it
> >will be 8 read operations for the blob alone.
>
> Why 8 read operations are needed for the blob column? As far as I know, an
> blob is seperated into two parts, why the reading of these two parts would
> require 8 read operations? Does "8 read operations" means 8 disk operations?
Because the blob will be stored on a hidden table in rows 2K in size
with the first 256 bytes will be in the row in the main table (and in
memory).
Kind Regards
--
Andrew Hutchings, MySQL Support Engineer, Americas
Sun Microsystems, United Kingdom
http://www.sun.com/mysql/
