Aaron Steinfeld

Holding more sig figs does make sense, but I think keeping maintaining an unknown origin unit may be difficult in terms of standardization. I'd be in favor of storing in...

Elaborated more above, please let me know if there are any more questions.

### Concerns around UX This seems like it's a redefining a fundamental building block of the product for a single use case, and in the process sacrificing others. It adds...

> I think the problem is that we assume the user does not want to see the full trace but instead only service calls. This is a very cumbersome experience...

To support server side paging, where we have no guarantee that we have the full result set in the browser. In this particular case, it may be a small enough...

> Currently, we are triggering graphql api for all keystrokes, can we limit the api calls, by triggering only when the user stops typing for a time period (eg 2...

The API support for this is being actively worked on as part of https://github.com/hypertrace/hypertrace-ui/issues/1099. Should hopefully land this week.

I think this solution makes sense in isolation for QS - it's along the lines of what I was thinking. Now, we need to make sure it will work at...

Looked into this more today. So we need support in all of: - Group By - Filter - Selection - Order by (this one wasn't mentioned, but looks like it...

> Secondly, with this approach, eventually, we will not need ColumnIdentifer, so I guess, we will deprecate it, right? Yeah, I thought it'd be more readable and simpler to handle...