 |
 |
Ah I see. They are basically building what is called "covering index". Composite index helps here because it fully covers the query, e.g., if you build a composite index on population and CountryCode, you can answer the query just by scanning one index, there is no need to touch data or join entries from two indexes. So that is why it is a big win. Our situation is different... Jacek On 01/08/2015 04:21 PM, Fabrice Jammes wrote: > Hi all, > > A silly idea: > a composite index on objectId, subChunkId (beware the order) > may avoid to create a temporary table for each subChunkId? > > Here's an interesting documentation about the weird behaviour of > MySQL query optimizer: > http://dasini.net/blog/2009/02/18/optimisation-de-requetes-comprendre-loptimiseur-de-mysql/ > > > And the official doc: > http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html > > FYI, Daniel and Jacek have ran some tests about it. > > Cheers, > > Fabrice > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1