Hi, It is a useful function. Actually for each query, now there is a queryId attached, and it can play as the traceid, I think. The left thing is recording each step's time cost. But if someone implement it, please be careful about the performance side effect.
Like Cassandra, there is a command called `tracing on | off`. If the tracing is enable, then a (distributed) write command will be split into about 5 steps and the query command will be split into about 8 steps (I forget the details), but it absolutely harmful for the performance and brings heavily replica inconsistency (because Cassandra will persist the tracing results). So, `tracing on` is disable by default and usually it is just enabled for a short time. Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 iotdb_contributor <[email protected]> 于2019年12月7日周六 上午2:04写道： > > > hi, > At present, iotdb has a very good design for monitoring the execution > status and time of SQL and it can be displayed to users intuitively. > However, when the user or we do the testing ourselves, we can't > intuitively feedback the direction we need to optimize. > Do we need to design a traceid, which is generated from the method that > reaches serviceimpl, and records the execution time of all important > methods in detail, so that the problem At a glance. > > > 各位好： > > 现在iotdb已经有一个非常好的监视模块，可以打印sql时间和状态等，但仅仅知道一个sql比较慢的时候还不能更快速的定位到慢在哪里，所以我们有没有必要实现一个traceid这类东西，从Tsserviceimp的入口方法开始追踪，包罗所有重要的函数，这样有利于我们直观的优化或分析数据库，或许对未来的集群版本提供更大的帮助！ > 以上只是猜想，烦请各位批评指正！
