WIP: query: prune TSDBInfos in query.remoteEndpoints.Engines()

[SuperPaintman]

• I added CHANGELOG entry for this change.
• Change is not relevant to the end user.

Changes

See #8597 for more details.

Important

In this implementation we ignore vector operations and offsets in queries. We need to compensate for them before pruning.

Verification

---

Issue: #8597

CC: @MichaHoffmann

[MichaHoffmann]

Note that this method here has the issue that the remote engine might query data that goes back further then mint of the remote query that we send. Think "last_over_time(X[24h])" - we query at time t but need data for t-24h until t.

I think this pruning should probably happen in the engine not here; but idk.

[SuperPaintman]

Note that this method here has the issue that the remote engine might query data that goes back further then mint of the remote query that we send. Think "last_over_time(X[24h])" - we query at time t but need data for t-24h until t.

Of course, I'll account for that in the final implementation.

Would queries like these also have an effect on this?

• foo{} offset 24h
• foo{} @ <timestamp>

I think this pruning should probably happen in the engine not here; but idk.

Do you mean in promql-engine repo?

That's probably a good idea, but I'm not sure how to prune tsdbInfos there. RemoteEngine interface only exposes high-level methods like MinT() or LabelSets(), so we will probably need to somehow pass back start/end to prune infos (otherwise it defeats the purpose).

An optional interface like this (and implement it later for remoteEngine)?

type RemoteEnginePruner interface {
    Prune(start, end time.Time) RemoteEngine
}

Or we can change the RemoteEndpoints interface:

// As a breaking change:
type RemoteEndpoints interface {
	Engines(start, end time.Time) []RemoteEngine
}

// Or backward compatible (optional interface):
type PrunedRemoteEndpoints interface {
	PrunedEngines(start, end time.Time) []RemoteEngine
}

Let me know if you have other ideas.

[MichaHoffmann]

Note that this method here has the issue that the remote engine might query data that goes back further then mint of the remote query that we send. Think "last_over_time(X[24h])" - we query at time t but need data for t-24h until t.

Of course, I'll account for that in the final implementation.

Would queries like these also have an effect on this?

• foo{} offset 24h
• foo{} @ <timestamp>

I think this pruning should probably happen in the engine not here; but idk.

Do you mean in promql-engine repo?

That's probably a good idea, but I'm not sure how to prune tsdbInfos there. RemoteEngine interface only exposes high-level methods like MinT() or LabelSets(), so we will probably need to somehow pass back start/end to prune infos (otherwise it defeats the purpose).

An optional interface like this (and implement it later for remoteEngine)?

type RemoteEnginePruner interface {
    Prune(start, end time.Time) RemoteEngine
}

Or we can change the RemoteEndpoints interface:

// As a breaking change:
type RemoteEndpoints interface {
	Engines(start, end time.Time) []RemoteEngine
}

// Or backward compatible (optional interface):
type PrunedRemoteEndpoints interface {
	PrunedEngines(start, end time.Time) []RemoteEngine
}

Let me know if you have other ideas.

Maybe Engines(minT, maxT int64) []RemoteEngine ? We could just bend the interface so that it only returns engines that overlap this time window.

[SuperPaintman]

Moved it to promql-engine: thanos-io/promql-engine#680