As discussed on GitHub, I've pushed a fix: https://github.com/pat/thinking-sphinx/issues/608
-- Pat On 16/09/2013, at 2:28 PM, Hasan Kumar Reddy Alugubelly wrote: > Hi Pat! > Even I am facing a similar situation right now. We have recently upgraded to > thinking-sphinx 3 and it generates unnecessary group by attributes to the > indexing query. The query takes forever (> 30 min) to finish in the mysql. > Just removing the group by attribute makes it complete in less than 9 minutes. > Is there a patch or a workaround which will help me solve this issue. We are > stuck at this as our app indexing is taking very long time, hence a few hours > to deploy > We are using MySQL as the database > > On Saturday, 6 July 2013 18:06:45 UTC+5:30, Pat Allan wrote: > The GROUP BY is added by default, just because it's pretty common that > there's aggregations which require it. Perhaps it's possible to have the > query generator smart enough to avoid this… I'd certainly welcome a patch > that made TS a little smarter in these situations. > On 02/07/2013, at 7:27 PM, Radosław Bułat wrote: > > > Thanks Pat for your reply! > > > > Ok, I understand that something internally changed in thinking sphinx but I > > can't understand why in my particular example GROUP BY is needed. It is > > just simple SQL query with LEFT JOIN clause. There are used no aggregate > > functions so why GROUP BY is needed? > > > > On Monday, July 1, 2013 1:25:25 PM UTC+2, Pat Allan wrote: > > Hi Radosław > > There was something in older versions of Thinking Sphinx that checked > > whether MySQL was being used, and then checked if that MySQL server had a > > particular flag set (to see whether GROUP BY clauses must be complete, or > > could be missing/incomplete). If the latter was true, then the GROUP BY > > clause was not included. > > > > I'm not particularly keen with having the special behaviour for one > > database, but I understand it's not ideal from a speed perspective for > > MySQL users. I'd be open to a patch that adding this behaviour in, but I'd > > much prefer a solution that offered appropriate hooks for other devs to > > extend the SQL generation themselves directly. I've no idea what that would > > look like, though, so even just the simpler patch would be a good start. > > > > Kind regards, > > > > -- > > Pat > > > > > > > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Thinking Sphinx" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/thinking-sphinx. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/thinking-sphinx. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/thinking-sphinx. For more options, visit https://groups.google.com/groups/opt_out.
