[ https://issues.apache.org/jira/browse/SOLR-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988391#comment-13988391 ]
Tomás Fernández Löbbe commented on SOLR-6039: --------------------------------------------- bq. I didnt' fully understand the changes you made when skimming your patch Besides adding the query section when there are no "GET_DEBUG_PURPOSE" requests (that it's on on the GET_FIELDS phase), one thing that changes with the patch is that the shard requests for all phases will require "debug=timing" if timing is needed. Then after the final phase those times are added. Before this change, the timing section didn't come back on queries with no docs (this is I think a previous than SOLR-5399), now it does. Another implication with this change is that all shard requests will be considered, and not only the last phase (will now show higher times). As I say before, the times for all shard responses are being added, and because many of those requests are sent in parallel, this means that the timing displayed may be higher than the clock time of the request. I think this is useful information anyway and should be considered more as a metric of how much each component is taking in all the request. > debug=track causes debug=query info to be suprsedd when no results found > ------------------------------------------------------------------------ > > Key: SOLR-6039 > URL: https://issues.apache.org/jira/browse/SOLR-6039 > Project: Solr > Issue Type: Bug > Affects Versions: 4.7 > Reporter: Hoss Man > Attachments: SOLR-6039.patch, SOLR-6039.patch, SOLR-6039.patch, > SOLR-6039.patch > > > Shamik Bandopadhyay noted on the mailing list that debugQuery=true wasn't > returning info about how the query was being parsed in SolrCloud. > Steps to reproduce... > * startup a simple 2 shard solr cluster using the example configs > * Load this URL: > ** http://localhost:8983/solr/select?q=Foo&debug=query > ** note that the debug=query causes a debug block including "parsedquery" > showing "title:foo" > * Load either of these URLs: > ** http://localhost:8983/solr/select?q=Foo&debug=query&debug=track > ** http://localhost:8983/solr/select?q=Foo&debugQuery=true (legacy short hand > option for enabling all debug options) > ** Note that the debug block exists, but *only* includes the distributed > "track" options - the query parsing debugging info is not available > * index the sample data (java -jar post.jar *.xml) > * Load either of these URLs: > ** http://localhost:8983/solr/select?q=Solr&debugQuery=true&fl=id > ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&fl=id > ** Note that now we have at least one matching doc, and the parsedquery info > is included in the debug block along with the tracking info > * Load either of these URLs: > ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0 > ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0 > ** Note: even though we have a matching doc, since rows=0 prevents it from > being returned, the parsedquery debug info again no longer works - just the > track debug info > ---- > The work around, for people who want don't care about the newer "debug > tracking" and what the same debug information as pre-4.7, is to enumerate the > debug options (ie: {{debug=query&debug=timing&debug=results}}) instead of > relying on the shorthand: {{debugQuery=true}} -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org