>> I think the problem is not merely one of documentation, but one of >> bad design. Up to now it was possible to tell what was what from >> counting the number of columns in the output; but with this design, >> that is impossible. That should be fixed. The first thing you have >> got to do is drop the alternation { failures | serialization_failures >> deadlock_failures }. That doesn't make any sense in the first place: >> counting serialization and deadlock failures doesn't make it impossible >> for other errors to occur. It'd probably make the most sense to have >> three columns always, serialization, deadlock and total. > > +1. > >> Now maybe >> that change alone is sufficient, but I'm not convinced, because the >> multiple options at the end of the line mean we will never again be >> able to add any more columns without reintroducing ambiguity. I >> would be happier if the syntax diagram were such that columns could >> only be dropped from right to left. > > Or those three columns always, sum_lag sum_lag_2, min_lag max_lag, skipped, > retried retries?
What about this? (a log line is not actually folded) interval_start num_transactions sum_latency sum_latency_2 min_latency max_latency failures serialization_failures deadlock_failures retried retries [ sum_lag sum_lag_2 min_lag max_lag [ skipped ] ] failures: always 0 (if --max-tries is 1, the default) sum of serialization_failures and deadlock_failures (if --max-tries is not 1) serialization_failures and deadlock_failures: always 0 (if --max-tries is 1, the default) 0 or more (if --max-tries is not 1) retried and retries: always 0 (if --max-tries is 1, the default) 0 or more (if --max-tries is not 1) Best reagards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp