List label values over a time period

[Yamakaky]

I'm doing a trace collection server that centralize traces from multiple distinct applications. I use the tag deployment.environment to differentiate the origins. In dashboards, I would like to have a list with all the deployments for the selected time period, so that I can select one. Having some outdated results is ok, but missing a live one is not.

For now, i use select value->>0 from _ps_trace.tag where key = 'deployment.environment', but it has a few problems:

• I don't think this table is part of the public API?
• Old, unused tags are never removed (#1571)
• There is no time selection available as tag is not a hypertable

A distinct(span_tags->>'deployment.environment') would work but would be slow for high volume databases. Maybe use a continuous aggregate? Would you consider adding a builtin way of doing that, maybe stabilize a tag API? That seems like a common use case.

[jgpruitt]

I'd like to try to reproduce the performance you're experiencing. What's the rate at which you are ingesting spans and how far back in time are you wanting to look for distinct tag values?

[Yamakaky]

With start_time > now() - interval '1 hour' and 17k spans, query time is 1s with select distinct (Parallel Custom Scan (ChunkAppend)) and instant with query tag (index scan).

select distinct(resource_tags->>'deployment.environment') from span where start_time > now() - interval '1 hour';
select value->>0 from _ps_trace.tag where key = 'deployment.environment';

Thanks to sql I have a few analysis dashboards, most of them are over at least 24h.

[jgpruitt]

I intend to work on this, however, I have some higher-priority work at the moment. Querying the _ps_trace.tag table directly will be the fastest approach. I think we need to add a public view for it. We have no plans at the moment to make the tag table a hypertable. I doubt that will happen. Querying the span table will be the most correct approach. Maybe you could speed it up with an index of some sort.

[Yamakaky]

OK. It's not high prio for me either.

An index would work for the recent chunks however I don't think it would for compressed chunks?