> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo days - 2026-09-10
> ClickStack demo days for 2026-09-10
Required dashboard filters
*Demo by [@pulpdrew](https://github.com/pulpdrew)*
Dashboard filters can now be marked required, so tiles don't load until a value is selected for them. Previously every filter was optional, and opening a dashboard built over a large source ran all of its tiles unfiltered before you'd narrowed anything down.
A filter definition has a new **Required** toggle. On its own it blocks the tiles that actually use the filter: the ones that reference it as a variable, and the ones receiving a broadcast value from it. In the demo, a service name filter broadcast to both the logs and traces sources blocked every tile on the dashboard, while a severity filter that only exists in the logs table blocked the log tiles and left the trace tiles loading as before.
A second option extends the requirement to every tile on the dashboard, whether or not the tile uses the filter as a variable or receives a broadcast value from it. Underneath, each filter type gained two fields: `minSelections`, where a value of 1 means required, and `isGlobalRequirement` for the dashboard-wide version. `minSelections` is a number rather than a boolean so that a matching `maxSelections` cap, and minimums above 1, stay available later.
Dependent filters aren't blocked by the required filters they depend on yet, so a filter whose option query references a required variable still queries its options before that variable has a value.
Dashboard filter and variable selections now also apply to the chart preview in the tile editor, as Brandon suggested while reviewing the required-filters PR. Previously variables and core filters were propagated into the preview but broadcast filters weren't, which was an inconsistency, and with required filters in place there's a performance argument for editing a tile with the same filters the dashboard applies. The **Apply filters** toggle is on by default and you can turn it off to see the tile both ways.
The toggle is forced off when the tile has an alert configured on it, because alerts evaluate without any filters applied. That way the preview matches what the alert will actually query.
When a required filter blocks the preview, the message in the tile editor now points at turning **Apply filters** off as the way past the block.
**Related PRs:** [#3078](https://github.com/hyperdxio/hyperdx/pull/3078) Support configuring dashboard filters as required, [#3093](https://github.com/hyperdxio/hyperdx/pull/3093) Optionally apply dashboard filters to tile editor preview, [#3098](https://github.com/hyperdxio/hyperdx/pull/3098) Add getBlockingRequiredFilterNames, update tile editor blocked copy
Live query progress on the search page
*Demo by [@wrn14897](https://github.com/wrn14897)*
Previously, a slow search showed an unqualified spinner for its whole duration. There was no way to tell whether ClickHouse was 5% or 95% of the way through a range, or doing anything at all, which is exactly the situation you're in when a source has a primary key that doesn't suit the query. The results table footer and the histogram's scanned rows and elapsed time strip now report ClickHouse's own progress counters: how long the query has been running, how many rows have been scanned, and a percentage. It's close to what the ClickHouse CLI shows while a query streams.
Progress comes from the `JSONEachRowWithProgress` format, which interleaves `{"progress":...}` lines with rows in the response body. Headers were a dead end: ClickHouse stops emitting `X-ClickHouse-Progress` once the body has started, and `fetch()` can't surface headers incrementally anyway. The format needs ClickHouse 25.1 or newer, so it's selected per connection from the reported server version, and older or unknown servers keep the existing non-streaming path.
The search page fetches one time window at a time rather than the whole range at once, so a week-long search runs day by day and stops once it has enough rows. Progress is calculated over the whole set of windows, and deliberately survives the gaps between them: clearing it on that edge made the bar vanish and the elapsed timer restart at every window, dozens of times over a month-long range. A window registers itself as in flight at 0% before it starts reading, so a just-opened window isn't credited its whole range.
This is only on the main search page. It's hidden during live tail, where the query refetches every few seconds and a bar would only flicker. With the short first window, a search that fills its `LIMIT` immediately shows about 0% for a moment before the bar disappears.
What streams is progress, not results. Rows still arrive a window at a time, and returning them as they're scanned needs streaming support on the ClickHouse side, which is being worked on, as Jordan asked about on the call. The proxy sitting in between adds its own complexity there, so it isn't built yet.
The chunking has a related gap that came up as feedback: while the histogram fills in chunk by chunk, nothing distinguishes a window that's still being queried from one that returned no data, and some indication of progress on the chart itself would help. That sits in a different part of the code from this change.
**Related PRs:** [#3103](https://github.com/hyperdxio/hyperdx/pull/3103) Show live ClickHouse query progress during a search (open). The day-by-day search windowing the bar reports over is older work and isn't part of this change; the incremental search windows landed in [#1125](https://github.com/hyperdxio/hyperdx/pull/1125) and chart chunking in [#1233](https://github.com/hyperdxio/hyperdx/pull/1233).