In version 8.0.0.65 I noticed the following: I had a query that took over 1 minute to run, then it returned the rows, however, the duration displayed was what you see in the screenshot. I think the duration displayed might be the grid data loading time or something similar, not the time it took the query to run and return the data.
Could you please fix the application to show the entire duration of the query? As it is, it is confusing and misleading.
In case it's already fixed, is the fix available in a production release? 8.0.0.65 is the latest version I downloaded.
8.0.0.65 is the latest generally available release.
Can we ask to what value your Fetch Count is set (default is 1,000 rows, I think),
and how many rows your query returned ?
I did some testing and it appears that the Duration displayed does indeed represent the execution time for the query, but according to the Fetch Count value.
If I set Fetch Count for All Rows, for example, and execute my query, I get a realistic execution time, per first screen snap below.
If I set the fetch count for a specified number (say, nnnn), it appears that I get the execution time for that query's fetch (e.g. top nnnn). Second snap below. However, if I right-click within the data grid and ask to Read All Rows, the execution time does not change.
We'll get Quest dev teams to take a look at this, to make sure of what Toad is displaying after query execution. At the very least, we may need to come up with a more accurate label than "Duration".
Fetch All: shows query duration to return all rows...
Again, the query took a long time to execute (over a minute) and all the rows came back together at the end and the duration displayed was under 1s. What I did was I started the query, I watched it for about 10s-20s, then I moved to another application window, and I came back to Toad when the query was done (the Toad icon in the task bar starts changing when the query is done). To my surprise the duration was under 1 second.
If I set Fetch Count for All Rows, for example, and execute my query, I get a realistic execution time, per first screen snap below.
That's definitely not my experience
One other thing I want to point out is that the sql being executed was a stored procedure and the last select query itself took a long time to execute due to the chosen execution plan, but the records came back together.There are some cases when sql server scans a lot of rows and sends back rows one by one or in small batches.
I just want to mention the bug I reported doesn't always happen, and I am not sure what the pattern is. It might have to do with the way sql server sends the records back to the client and how and when Toad measures the duration. I have a case, the same stored procedure, very slow, it exhibited the behaviour I mentioned above. I made some changes and I reduced the execution time from roughly a minute to about 4s and now Toad displays the duration properly.
Imo, as soon as you execute the query that's when you should start the timer. It would be nice to be consistent.
I've reached out to R&D team to take a closer look at the issue described here, I assume that more details will be required to examine the issue, can you share a quick video showcasing this issue with the displayed query rendering such an outcome?
