maria-discuss team mailing list archive

[pslawek83 <pslawek83@xxxxx>]

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_lookupON  raw_stats_lookup_id =  raw_stats_lookup.idWHERE 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@xxxxxxxxxxx> 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