On 2011-03-05 15:23, Fabian Groffen wrote: > On 05-03-2011 15:01:27 +0100, Martin Kersten wrote: >> I thought we had decided, after several discussions, that the >> mclient -t option remains available on mclient >> with the intended semantics of approximate timeing > > I thought we agreed that timing the way it is done (non-server-side) > doesn't make any sense. > _______________________________________________ > Checkin-list mailing list > [email protected] > http://mail.monetdb.org/mailman/listinfo/checkin-list
I thought the consensus was what I wrote. See attachment. -- Sjoerd Mullender
--- Begin Message ---It seems to me what we need is the following. - The old behavior back so that we can compare old times with new ones. However, these times should be clearly labeled as unreliable (e.g. by having to use some weird option). - The server should report the times *it* measured for each query it executes, possibly broken down like in MonetDB/XQuery into parse time and execute time. I expect this to be relatively cheap (just two or three calls to gettimeofday() or some such function), so perhaps we can do this always. - The times should be reported on stderr and be easily parsable. In interactive mode, they could always be printed, but in non-interactive mode they should *not* be printed, unless explicitly asked for. Or we could make it a standard feature of the SQL mode of printing the results (like the rows affected). - Just before times are printed to stderr, stdout should be flushed by mclient so that you can easily combine stdout and stderr (i.e. >& file). - The -i option should not imply -e. If you want the queries echoed, ask for them. It's not that hard to add -e. The reason I want times to go to stderr and not to stdout is that only then is it possible to send the query output one way (to file or even /dev/null) but keep the timing information. On 2011-01-30 11:31, Fabian Groffen wrote: > On 30-01-2011 11:24:53 +0100, Stefan Manegold wrote: >> I see no reason to combine two IMHO independent features. > > good point, at least both have to be enabled/disabled independently > >> ( >> ... in particular since '-i' does already work differently in different >> contexts (which I consider OK as it is now, as it seems well defined to me) >> ) > > ( really? what differences are you referring to? I thought it just > forces the client to think it is reading from console, and should hence > process line by line, asking the server after each line what it thinks ) > >> I am not sure, though, whether I understand when and how and why either -e >> or -i tirgger the new timing display as documented in my previous mail. >> Any explanation would be appreciated (can be interactive on Monday). > > The SQL timer can only emit a timing which makes sense if a single > statement is being executed. This can only be deduced in line by line > mode (which happens to be always interactive, hence -i). > >> ps: I'd suggest to continue the mclient discussion "life" & interactively on >> Monday during/after MADAM --- I consider that will be more efficient and >> effective, in particular as misunderstandings can be solved quicker and >> easier ... > > Unfortunately I have to wait at home for some mechanic to check the > state of some water component in my house, so I won't be there. > > Bottom line for me, is that that the server should optionally emit the > timings, and the client should print them to stderr, like XQuery mode > does/did. When the server doesn't send the timings (cheaper protocol > wise in day to day use) the current SQL timer can stay as just an > indication. -- Sjoerd Mullender
signature.asc
Description: OpenPGP digital signature
--- End Message ---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Checkin-list mailing list [email protected] http://mail.monetdb.org/mailman/listinfo/checkin-list
