Re: How to handle secondary keys in partitioning?
A couple of follow on questions for Mattias:
For a non-Partition table, "where sender_id=1 ordered by date" together with "INDEX(sender_id, date)" will (I think) avoid a filesort. Seems like in a Partitioned table, each partition could deliver the rows in order, and then the priority queue could put them together. Or is that asking for more smarts than is in Partitioning today? (I note that you said "and there will be an additional sorting cost".)
"the cost for index writes should be lower for partitioned tables, since the b-tree depth is lower per partition than it would be for a non partitioned table" -- isn't that offset by the effort to figure out which Partition to reach into?
Subject
Views
Written By
Posted
4302
May 04, 2010 12:46AM
2415
May 04, 2010 01:29PM
2056
May 04, 2010 04:30PM
2265
May 05, 2010 02:20AM
Re: How to handle secondary keys in partitioning?
2107
May 06, 2010 12:04AM
2519
May 06, 2010 03:23PM
2161
May 06, 2010 10:50PM
2130
May 07, 2010 02:38AM
2081
May 08, 2010 05:31PM
2136
May 09, 2010 04:37AM
2028
May 09, 2010 12:41PM
2011
May 09, 2010 01:23PM
2104
May 12, 2010 05:29AM
2548
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.