What storage backend are you using?

I'm not particularly opposed to this change. Even though I do not recall similar complaints, I assume if someone uses ES as storage with indices rotated regularly, then having a time range as a hint might narrow down which indices to query. However, I am not sure how that would work when people use index alias, it would require some kind of support on ES side to use the time range hint.

Other official Jaeger backends are kv-stores and don't need help looking up by trace ID.

our backend is clickhouse. Clickhouse is not good at querying item by id, especially when the id is actually a random number.

We simply have too many traces, about 4 billion traces per day. that would need lots of memory if holding them in memory.

for kv store, it can simply ignore the start and end time.

this feature sounds like more general case as the API assume global scanning without any other options.

@yurishkuro, this would greatly benefit us given the volume of spans we ingest into our click house cluster. we would be more than happy to contribute the enhancement as well.

go for it.

Speaking of ClickHouse: are you using https://github.com/jaegertracing/jaeger-clickhouse ? I recently opened #4196. There is another implementation in OTel Collector Contrib, which has an additional small table, as I understand for looking up time range based on trace-id

@yurishkuro Thx for the information. we had evaluated the index table solution long ago. It does not help too much as the trace id is a random number. Clickhouse index does not help with random numbers.

When the traffic volumn is not high, the index table solution can be used.

I will work on the time parameters and send the PR. Thx