Comments on: Clustering indexes vs. Covering indexes http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/ Thu, 02 Feb 2012 04:10:04 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Hot Column Addition and Deletion Part II: How it works | Tokutek http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-93 Hot Column Addition and Deletion Part II: How it works | Tokutek Thu, 07 Apr 2011 17:13:11 +0000 http://clustering_indexes_vs_covering_indexes#comment-93 [...] since this is TokuDB, you also get to define clustering indexes, which reference all columns and therefore speed up lots of queries. The HCAD message gets injected [...] [...] since this is TokuDB, you also get to define clustering indexes, which reference all columns and therefore speed up lots of queries. The HCAD message gets injected [...]

]]> By: Partitioning, Free Lunches, and Indexing Part 2 | Tokutek http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-92 Partitioning, Free Lunches, and Indexing Part 2 | Tokutek Fri, 28 Jan 2011 19:36:46 +0000 http://clustering_indexes_vs_covering_indexes#comment-92 [...] up with the insertion load when you turn them all on. The first problem is solved by using TokuDB clustering indexes. The second is also solved by TokuDB, because it’s so fast at [...] [...] up with the insertion load when you turn them all on. The first problem is solved by using TokuDB clustering indexes. The second is also solved by TokuDB, because it’s so fast at [...]

]]> By: Xaprb http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-90 Xaprb Mon, 08 Jun 2009 02:02:38 +0000 http://clustering_indexes_vs_covering_indexes#comment-90 Right. The irritating "key" vs. "index" mis-nomenclature in MySQL strikes again. I understand you now! Right. The irritating “key” vs. “index” mis-nomenclature in MySQL strikes again. I understand you now!

]]> By: Bradley C. Kuszmaul http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-89 Bradley C. Kuszmaul Mon, 08 Jun 2009 01:57:36 +0000 http://clustering_indexes_vs_covering_indexes#comment-89 I may be misunderstanding your question, but I think the point we were trying to make is that the *key* of a clustering index is typically smaller than the *key* of a covering index. Because in MySQL standard syntax, there is no way to add a column to an index without adding it to the key. Bigger keys can suffer performance problems. (For example, they may reduce the fanout of B-tree-like data structures). The clustering key syntax allows us to store all the extra columns without throwing them into the key. I may be misunderstanding your question, but I think the point we were trying to make is that the *key* of a clustering index is typically smaller than the *key* of a covering index. Because in MySQL standard syntax, there is no way to add a column to an index without adding it to the key. Bigger keys can suffer performance problems. (For example, they may reduce the fanout of B-tree-like data structures).

The clustering key syntax allows us to store all the extra columns without throwing them into the key.

]]> By: Xaprb http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-88 Xaprb Mon, 08 Jun 2009 01:19:22 +0000 http://clustering_indexes_vs_covering_indexes#comment-88 Why are clustering indexes much smaller than covering indexes? Unless I'm misunderstanding your meaning, this is really not true of InnoDB, for example. Or are you talking about your indexes, and not indexes in general? Why are clustering indexes much smaller than covering indexes? Unless I’m misunderstanding your meaning, this is really not true of InnoDB, for example. Or are you talking about your indexes, and not indexes in general?

]]> By: Bradley C. Kuszmaul http://www.tokutek.com/2009/05/clustering_indexes_vs_covering_indexes/#comment-91 Bradley C. Kuszmaul Fri, 29 May 2009 05:12:54 +0000 http://clustering_indexes_vs_covering_indexes#comment-91 Oops, adding z to cvr_idx made the index infeasible (17 columns). I guess that confirms the argument about simplicity... Oops, adding z to cvr_idx made the index infeasible (17 columns). I guess that confirms the argument about simplicity…

]]>