I believe the optimizer does know that InnoDB has a clustered primary
key, because ha_innobase::primary_key_is_clustered returns true
On Wed, Mar 3, 2010 at 2:22 PM, Gavin Towey <gtowey@stripped> wrote:
> Yes, but the optimizer doesn't know that.
> -----Original Message-----
> From: vegivamp@stripped [mailto:vegivamp@stripped] On Behalf Of Johan De Meersman
> Sent: Wednesday, March 03, 2010 6:16 AM
> To: Zardosht Kasheff
> Cc: Jonas Oreland; mysql@stripped
> Subject: Re: Re bug#45458
> Unless I'm very much mistaken, InnoDB tables always have a clustered index
> as their primary key.
> On Wed, Mar 3, 2010 at 2:58 PM, Zardosht Kasheff <zardosht@stripped> wrote:
>> Hello Jonas,
>> Thank you for filing this feature request. Are there plans to add
>> support for clustered indexes in MySQL soon? This is something I have
>> been researching on and off for a while now. Here are my thoughts.
>> It seems that there are two parts to this feature request:
>> 1) a new flag that allows the storage engine to report that an index
>> is clustered
>> 2) changes to the optimizer to properly support clustered keys.
>> I like #1. The way that I dealt with it was not as good. I added
>> handler::supports_clustered_keys(), and used that function and
>> HA_CLUSTERING from my patch to determine if an index is clustered.
>> Your method is better.
>> As for #2, I do not think it is enough. Here are two other locations
>> of code I know that will need to be modified:
>> 1) find_shortest_key in sql/sql_select.cc. (This will be an addition
>> to MySQL bug #39653)
>> 2) get_best_ror_intersect in sql/opt_range.cc. This is for
>> index_merge. A patch of what I have done is in the attached file
>> 9-index_merge_clustering.txt. This patch was the result of a long
>> thread on the internals alias (which you may want to CC for this
>> discussion). The link to the thread is
>> There may be more places that need to be modified. I think the
>> approach to finding out if other places need to be modified is to
>> pattern match off of how the optimizer deals with clustered v.
>> non-clustered primary keys. It does so by having a function
>> handler::primary_key_is_clustered. I think one needs to search the
>> optimizer for all instances of this function, see why it is being
>> called, and see if it applies to clustered v. non-clustered secondary
>> keys as well.
>> On Wed, Mar 3, 2010 at 5:57 AM, Jonas Oreland <jonas@stripped> wrote:
>> > Hi,
>> > I just filed http://bugs.mysql.com/bug.php?id=51687
>> > which is very related to your bug#45458.
>> > If you would care to look at it and provide feedback,
>> > I would appreciate it.
>> > /Jonas
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee, you are notified that
> reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly
> prohibited. Please notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
> not accept liability for any loss or damage caused by viruses or errors or omissions in
> the contents of this message, which arise as a result of e-mail transmission.
> [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA,
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1