Hello pslawek83, 

as Sergei has already told you, the issue is not the uniqueness of the indexes.

Some notes after reading your queries and the tables:

- I see two versions of the query, one having `attrib=5`, the other without.
- on table raw_stats_lookup, you do not have an index on (domain, id) or even just on (domain).
- on table raw_stats_other_copy, the 4-column index is not the best for this query. The date (and perhaps attrib) should be promoted at the first positions of the index. If you also include `impressions` on the index, the query will not have to read the table, all the data will be available from the index.
So, an index on either (date, attrib, raw_stats_value_id, raw_stats_lookup_id, impressions)  or on (date, raw_stats_lookup_id, attrib, raw_stats_value_id, impressions)  would be much better than what you have now.

So, in all, the additional knowledge you mention is not useful for the optimizer, as the index is not really appropriate for this query. 

Pantelis



On Thu, Mar 6, 2014 at 8:06 PM, pslawek83 <pslawek83@o2.pl> wrote:
Ok i wasn't able to reproduce the issue fully, now data is different ... but again, "skipped rows" number changes, and index sizes differ a lot:

Uniq index:
http://screencast.com/t/SrBS1L5xeB8
http://screencast.com/t/3dVMU7b69AH2

Normal index:
http://screencast.com/t/Zl5Jm2OZ
http://screencast.com/t/P3SA8U6duly


But again, unique index is working much worse than not unique... while it's bigger
http://screencast.com/t/rjexoWKwFF

http://screencast.com/t/qYdsmRbRbmG7


I'll quickly explain how tables were created... i first took part of the data with unique index, and made smaller copy, thats table 1
Then i just copied the table changed the index to non-unique.

After this i copied the tables once again to be sure files are not fragmented, etc.

SHOW WARNINGS returns nothing in both cases. It seems that the additional knowledge (only single row with same data) should make the optimizer and query behave better but it's actually behaving much worse...


--
Query for reference:
EXPLAIN extended SELECT attrib_id, raw_stats_value_id, sum(impressions)
FROM raw_stats_other_copyi1_copy 
INNER JOIN raw_stats_lookup
ON  raw_stats_lookup_id =  raw_stats_lookup.id
WHERE domain = 'mydomain.com'
AND date = '2014-02-10'
GROUP BY attrib_id, raw_stats_value_id;
--


Thanks,
Slawomir.




Dnia 6 marca 2014 17:46 Sergei Golubchik <serg@mariadb.org> napisał(a):

Hi, pslawek83!

On Feb 17, pslawek83 wrote:
> Hi Guys,
> any comments on this issue? It seems that partial unique indexes can't be used in joins.
> https://mariadb.atlassian.net/browse/MDEV-5663

Please, show EXPLAIN EXTENDED (and SHOW WARNINGS after it) for this
query of yours.

> * Why the server is treating same indexes differently depends on if
> they're UNIQUE or not

It doesn't, there're almost no differences between UNIQUE and non-unique
indexes from the optimizer point of view. Optimizer knows that for a
unique index there can be at most one matching row (if all index parts
are known and are NOT NULL), for non-unique indexes there can be more.
That's basically the only difference.

> * That's probably not optimizer issue, as we can't FORCE the index

You cannot force the index if it is not applicable at all.

> * What's internal difference between unique and non-unique index (eg.
> memory / file representation / data structure)

none.

> * What each index type is suitable for, considering query optimization
> (as there's no data i was able to find on topic)

Aria only supports BTREE indexes anyway.

Regards,
Sergei



_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to     : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp