Andrey, I think you're right. This logic was once refactored so that actual execution happens only when cursor iteration starts, and I guess metrics were not fixed accordingly. Can you file a ticket?
-Val On Wed, Nov 8, 2017 at 9:27 AM, Andrey Kornev <andrewkor...@hotmail.com> wrote: > (Changed the subject to maybe make people actually read the posting.) > > Anyway, if somebody (who knows that code) could take a quick look to see > if the duration is indeed computed correctly (or not), that would be > greatly appreciated! > > Thanks > Andrey > > ________________________________________ > From: Andrey Kornev <andrewkor...@hotmail.com> > Sent: Sunday, November 5, 2017 12:17 PM > To: dev@ignite.apache.org > Subject: Query duration metrics > > Hi, > > It appears as if the query duration metric is a bit misleading. > > GridQueryProcessor.executeQuery() doesn't actually "run" the query. It > simply delegates query execution to a closure passed in as a parameter. The > closure may or may not actually execute the query. In some (all?) cases, > the closure simply creates and returns an Iterable (how does > IgniteH2Indexing.runQueryTwoStep, for example). Actual query execution > happens at some point later when user instantiates an Iterator from the > Iterable. What's in fact recorded (by GridQueryProcessor on line 2477) as > the "query duration" is just the query parsing stage as well as some > query's AST manipulation logic that tries to convert the regular regular > query to a map/reduce style query. So, it's basically a "prepare statement > duration" that is currently reported as "query duration". > > Am I missing something? > > Thanks > Andrey >
