Comments on: Introducing Multiple Clustering Indexes

By: Clustering indexes vs. Covering indexes | Tokutek

Clustering indexes vs. Covering indexes | Tokutek — Thu, 19 Aug 2010 19:45:42 +0000

[...] I (Zardosht) posted an entry introducing clustering indexes. Here, I elaborate on three differences between a clustering index and a covering [...]

By: How clustering indexes sometimes help UPDATE and DELETE performance | Tokutek

Thu, 19 Aug 2010 19:43:13 +0000

[...] recently posted a blog entry on clustering indexes, which are good for speeding up queries. Eric Day brought up the concern that clustering indexes [...]

By: MySQL 5.1 Grammar Changes to Support Clustering Indexes | Tokutek

MySQL 5.1 Grammar Changes to Support Clustering Indexes | Tokutek — Thu, 19 Aug 2010 19:42:12 +0000

[...] blogging about TokuDB’s multiple clustering indexes feature, Baron Schwartz suggested we contribute the patch to allow other storage engine to [...]

By: Improving TPC-H-like queries – Q17 | Tokutek

Improving TPC-H-like queries – Q17 | Tokutek — Thu, 19 Aug 2010 19:41:11 +0000

[...] Summary: A query like TPC-H Query 17 can be sped up by large factors by using straight_joins and clustering indexes. (This entry posted by [...]

By: Mark Callaghan

Mark Callaghan — Mon, 15 Mar 2010 21:19:49 +0000

This is very nice. I missed this post when you first wrote it. It can be used to provide much better bounds on worst-case query performance (a few disk reads versus thousands) and do a much better job at making queries ‘online’.

By: Kristian Nielsen

Kristian Nielsen — Fri, 29 May 2009 03:07:22 +0000

Ah, now I think I see the difference between this and normal covering indexes. The difference here is that the extra fields are only stored in the leaf nodes (assuming Btree index). The keys in interior nodes need not store the extra fields, unlike in traditional covering indexes where the extra fields needlessly increase the key size proper.

That might be useful, especially when the row size is much bigger than the key size (not at all uncommon).

By: Zardosht Kasheff

Zardosht Kasheff — Thu, 28 May 2009 23:59:45 +0000

@Venu, with TokuDB, we typically measure compression ratios of 3x to 12x relative to the amount of raw data in a table. Since a clustering index is another copy of the table in a different sort order, it will probably consume somewhere between 1/3 and 1/12 of the table’s raw data size.

By: Venu Kalyan

Venu Kalyan — Thu, 28 May 2009 21:34:59 +0000

Can you describe how much extra storage is needed for each add-on clustered index/table ?

By: Zardosht Kasheff

Zardosht Kasheff — Thu, 28 May 2009 20:53:26 +0000

@Kristian, good questions. I will address covering indexes vs. clustering indexes in a blog post later today.

By: Kristian Nielsen

Kristian Nielsen — Thu, 28 May 2009 04:38:15 +0000

How is this any different from a covering index in MyISAM (or InnoDB) obtained by just appending all remaining columns after the indexed keys?

Especially with the restriction on no unique indexes, that seems to be exactly the same?

From the description it sounds like this is just a syntax shortcut for creating covering indexes, which are supported in MyISAM and InnoDB (but not Falcon). But a covering index is not a clustered index, since as Eric writes it does not improve insert/update speed in any scenarios.