Re: How to handle secondary keys in partitioning?
Rick: the priority queue is used for index reads that requires sorted results, and the 'additional sorting cost' is the cost of that priority queue.
The calculation of which partition id a row belongs to is in RANGE/LIST a binary search O(log(num_partitions/list_values)), and in KEY/HASH a simple modulo operation O(1) and the partitioning expression, and is not related to the index. The index management is done in the storage engine used (MyISAM, InnoDB etc).
John: you are correct that it will still need to read from 5 indexes. My thought was if you want to partition by 25 partitions, maybe it would make sense to partition on two different columns, if the select queries is a mix of either of the two columns (recipient_id or sender_id). Also these matching subpartitions will be only a 1/5 of the size of the table. It all depends on what the usage are and where you want the gain.
So my idea to add subpartitioning was that you would make use of pruning for both recipient_id and sender_id, as a sort of compromise if you query a lot on sender_id too.
Subject
Views
Written By
Posted
4346
May 04, 2010 12:46AM
2435
May 04, 2010 01:29PM
2075
May 04, 2010 04:30PM
2293
May 05, 2010 02:20AM
2136
May 06, 2010 12:04AM
Re: How to handle secondary keys in partitioning?
2537
May 06, 2010 03:23PM
2183
May 06, 2010 10:50PM
2150
May 07, 2010 02:38AM
2101
May 08, 2010 05:31PM
2167
May 09, 2010 04:37AM
2052
May 09, 2010 12:41PM
2037
May 09, 2010 01:23PM
2125
May 12, 2010 05:29AM
2565
May 06, 2010 12:34AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.