maria-discuss team mailing list archive

[Pantelis Theodosiou <ypercube@xxxxxxxxx>]

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@xxxxx> 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@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
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-discuss
> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp
>
>