I wanted to run a Data Explorer query to return a large amount of data so I could export the lot to CSV. Problem is, the page is crashing my machine - the query triggers graphing, and the graphing code can't handle the data!

This screenshot of the insane graph was just barely obtained by another user:

I'm currently unable to modify the SQL as it kills the browser (latest Chrome on a Mac).


Initially I thought it was simply due to the amount of data and perhaps that pagination would help, however the comments (thanks guys!) have uncovered that it was the graphs being drawn.

  • 1
    Your results are already limited to 50,000 records, which performs adequately in all browsers. The issue here is (most likely, since it's hard to analyze with the tab crashing) that your query is triggering the graphing results too, which seems to not handle this result set very well.
    – Tim Stone
    Commented Apr 5, 2014 at 17:08
  • 2
    For kicks, the graph it produces is kind of ridiculous.
    – Tim Stone
    Commented Apr 5, 2014 at 17:11
  • Thanks Tim, I thought it was unlikely that it was allowing me to bring back enough data to crash the browser. I tried to do a little profiling to see what was running slow, but it crashed to early to get any profiling data back. Good point on the graph. It would still be quite nice to have pagination thought :-) Commented Apr 5, 2014 at 17:19
  • For a new similar query I deleted the graph tab DOM element in the chrome dev tools and it seems to be working. Whether that fixed it or whether it's unrelated who knows - but it's not crashing :-) Commented Apr 5, 2014 at 17:27
  • 1
    Yeah, I was able to profile it. I'll decide on the best way to fix that.
    – Tim Stone
    Commented Apr 5, 2014 at 17:27
  • Cool thanks Tim, just read somewhere you're the man behind the data explorer - it's a great tool, keep up the good work :-) Commented Apr 5, 2014 at 18:01
  • 1
    Just FYI, this is most definitely the correct place for questions about the Data Explorer. Commented Apr 6, 2014 at 2:49

1 Answer 1


As part of implementing multiple result sets I'm going through and cleaning up various parts of the query pipeline, and that happened to include a preliminary fix for this issue.

The change defers the rendering of the graph until the first time that the tab is actually shown, which will at least prevent the browser from freezing/crashing right away. I may also introduce a warning in cases where the number of datapoints you have is significantly more than the useful resolution of the graph, so that you know even before clicking the tab that there might be an issue.

Ideally we could detect this during the rendering of the series in the event it was taking a long time, but flot currently only has hooks that execute before each series, which is probably too late for cases like this (we'd have to wait for the first series to finish to know there was an issue, and it likely took a long time for even just one of the three of them to be rendered here).

  • Cool, thanks Tim. I didn't realise it was open source, I've got some ideas if you want a hand, as I've been dabbling with data visualisation recently in my day job. I'll drop you a line on github if I think of anything? Commented May 10, 2014 at 21:39
  • 1
    Yeah, feel free!
    – Tim Stone
    Commented May 10, 2014 at 21:44
  • Is this preliminary fix still in place? Is that why I'm able to interact with the page for a couple of seconds before it freezes? You saw my recent (duplicate, sorry) bug report, but it actually happens to me somewhat frequently.
    – Jason C
    Commented Jul 19, 2014 at 3:45
  • @JasonC I don't think that this branch has been deployed to the public instance yet.
    – Tim Stone
    Commented Jul 19, 2014 at 4:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .