If I'm reading our logs correctly, the db query takes a reasonable amount of time: 140ms for the failed search vs. 168ms for the successful followup. So I don't think the query itself is the issue.
As before, the failed search gives us a series of OpenSRF log messages, then the "flushing data from socket..." message about 1 second later, then one final log entry for that trace 60-70 seconds after that.
Another example of a failed search (no hits) which succeeds on a second attempt (multiple hits), this time with Postgres query durations:
http:// paste.evergreen -ils.org/ 636
If I'm reading our logs correctly, the db query takes a reasonable amount of time: 140ms for the failed search vs. 168ms for the successful followup. So I don't think the query itself is the issue.
As before, the failed search gives us a series of OpenSRF log messages, then the "flushing data from socket..." message about 1 second later, then one final log entry for that trace 60-70 seconds after that.