Gian Merlino

> The log line I searched was something like `Started ServerConnector@6e475994{HTTP/1.1, (http/1.1)}{0.0.0.0:8102}` which happens roughly at the 4th second after the tasks start. And runNotice at the overlord gets stuck...

Some recent work in this area of SeekableStreamSupervisor: - Eliminate some unnecessary metadata calls: https://github.com/apache/druid/pull/13328 - Don't ever queue more than one RunNotice at a time: https://github.com/apache/druid/pull/13334 - Contact tasks...

I think there are actually two root causes of ingestion lag: 1. Bottlenecks in the Overlord around operations like leader failover, task discovery, segment allocations. If the Overlord cannot execute...

Any idea if this patch would help with https://github.com/apache/druid/pull/15276#issuecomment-1786003447? I just noticed some weird behavior where an IT repeatedly fails on an `npm` step even after multiple attempts to re-run...

Possibly the same issue as #17949? Fwiw, I tried this query with `"plannerStrategy": "DECOUPLED"` and it generated the correct plan. So the issue must be with the coupled planner rules,...

Good to know! Fwiw, there is a current effort led by @kgyrtkirk to push towards decoupled planning being the primary planning method, which should be helpful.

It is actually possible to do this today! Although, the way you do it is not documented. But maybe we should document it? It involves placing a list of segments...

Because Druid is a multi-service system, we're generally expecting the Docker image to be launched using Docker Compose rather than directly. You can check here for a tutorial: https://druid.apache.org/docs/latest/tutorials/docker/

Still seems relevant, reopening.

Hi @ColeAtCharter. The `/druid/v2/candidates` API does not currently take into account segment pruning, although `/druid/v2/` and `/druid/v2/sql/` (the actual query APIs) do. I tried to repro the issue on `/druid/v2/`...