Otherwise it is hard to find out for what period etc the query was. Ideally we would add segmentId instead of segmentHash but would need to refactor some code from segmentQueryDecorator to the segmentClass (the method that finds the segmentId for a segment)...
SELECT /* 2019-11-25,2019-11-26 sites 1 segmenthash 6fb490cfce17323e01f4d11d61ea9679 */ /* Core */ count(distinct log_visit.idvisitor) AS `1`, count(*) AS `2`, sum(log_visit.visit_total_actions) AS `3`, max(log_visit.visit_total_actions) AS `4`, sum(log_visit.visit_total_time) AS `5`, sum(case log_visit.visit_total_actions when 1 then 1 when 0 then 1 else 0 end) AS `6`, sum(case log_visit.visit_goal_converted when 1 then 1 else 0 end) AS `7`, count(distinct log_visit.user_id) AS `39` FROM piwik_logtmpsegmentde86627ef24972fd077a35a9eb0dc563 AS logtmpsegmentde86627ef24972fd077a35a9eb0dc563 INNER JOIN piwik_log_visit AS log_visit ON log_visit.idvisit = logtmpsegmentde86627ef24972fd077a35a9eb0dc563.idvisit
I was looking at the code for the SegmentQueryDetector code and it seems like it should be called no matter what (since Segment::getSelectQuery() is called which calls getSelectQueryString() on the LogQueryBuilder. Is it not doing that currently?
I think the segmentQueryDecorator maybe gets only called when the
create temporary table select segmentquery is being executed?
I see, there's an
if I didn't notice...