[Monetdb-developers] MonetDB: default - implement timing per server response for resu...
Fabian.Groffen at cwi.nl
Fri Jul 16 20:29:22 CEST 2010
> While I like the new timing feature as well as the convenient formatting for
> human readability, I am wondering about two potential changes / extensions:
> (a) While the time formatting is convenient for human readbility, it might
> be less convenient for automatic (post-)processing, e.g., creating
> performance figures. For that, plain unformatted microseconds (in
> addition to the human-readable format) might be more convenient.
mtest will never see it, becuase it either uses the raw formatting, or
the special test-formatter which is designed to avoid differing output.
This timing information is only available in the one and only output
formatter that ordinary users should use. (That's why it displays
> (b) The "old" (still existing) "Timer" information is sent to stderr,
> thus, one can seem the Timer output without the need to grep through
> (potentially large) output, e.g., by simply redirecting the output to a
> file or even /dev/null --- obviously, aligning stderr & stdout in case
> of large multi-query scripts is then left to the user.
> The new timing output goes (together with the queries status summary
> like how many result tuples were produced) to stdout (only).
The old timer is left untouched. I disagree it should go to stderr (the
other day I found a roommate who didn't really like that either,
incidentially she happened to be the source of inspiration for
implementing the "new" timer). It is just meta information about what
the user sees. This is meant for ordinary users, not power users who
need microsecond precision of 5 flavours for their experiments.
Of course discarding the output, and only looking at the timing is
highly questionable, since that superb time you got might be actually
from the time that the server didn't do much e.g. due to some
concurrency problem... But then, this completely falls under the
aforementioned experiments setting, which this "new" timer doesn't even
try to address.
> (c) As the announcement (changelog) says, the new timing output is only
> produced with the "sql" formatter (i.e., not with, e.g., "raw" or
> "test", and hence, also not by default with `-s <sql-statement>` (unless
> one explicitly requests `-f sql`).
Just don't use -s, use the client interactively. A normal user should
never be confronted with raw output in my opinion.
> For (a) & (b) would it be an option to consider to also send the plain
> unformatted times in microseconds to stderr to (better) support automatic
> post-processing of the timings?
No. Just don't overdo it. It was never necessary in the past (isn't -t
just an XQuery-oriented feature?), and it doesn't make sense to me in
the near future either. If you want to monitor the time it takes to
query something, you should have hooked it up in your application
anyway, since it's trivial.
> To cover also (c), we could consider doing that with all formatters, not
> only with "sql".
No. For that you already have your -t switch to the client.
More information about the developers-list