On 01/31/2013 04:41 AM, Timour Katchaounov wrote:
> Igor,
> 
> Let me know if I can push the patch below. It fixes the bug
> according to our last discussion. If the number of group_list
> elements was known, I could add a test already in the beginning
> of the function, however such a counter doesn't exist, and I
> didn't want to complicate the code just for this special case.
> That's why the test is done where it is now.
> 
> Timour
> 
> 
> ------------------------------------------------------------
> revno: 3622
> revision-id: tim...@askmonty.org-20130131120040-oan9zei8ojyco178
> parent: ser...@pisem.net-20130128081223-mp9rsd3t9soz8lly
> fixes bug(s): https://mariadb.atlassian.net/browse/MDEV-641
> committer: tim...@askmonty.org
> branch nick: 5.3-md641
> timestamp: Thu 2013-01-31 14:00:40 +0200
> message:
>   Analysis:
>   Range analysis discoveres that the query can be executed via loose
> index scan for GROUP BY.
>   Later, GROUP BY analysis fails to confirm that the GROUP operation can
> be computed via an
>   index because there is no logic to handle duplicate field references
> in the GROUP clause.
>   As a result the optimizer the optimizer produces an inconsistent plan.
> It constructs a
>   temporary table, but on the other hand the group fields are not set to
> point there.
> 
>   Solution:
>   Make loose scan analysis work in sync with order by analysis. In the
> case of duplicate
>   columns loose scan will not be applicable. This limitation will be
> lifted in 10.0 by
>   removing duplicate columns.
> 
> 


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

Reply via email to