Comment 1 for bug 1703400

The slowest query is getting scan_data_json which is known to be a large unwieldy field, there's a query that took about 1.5 seconds with that. However, then the next query doesn't start until about 1.8 seconds after the slow one finished. It sounds weird it would take that long to chew through the data, so I think this may have hit a generic I/O slowness error we've been seeing.

I'll check to see if we can optimize this somehow.