Is partition dimension during ingestion taken into account during aggregation queries with filtering?

Let’s say I have the following ingestion spec:

{
“type”: “index_hadoop”,
“parser”: {
“type”: “string”,
“parseSpec”: {
“columns”: [“dim_1”, “dim_2”, “dim_3”, “met_1”],
“dimensionsSpec”: {
“dimensions”: [“dim_1”, “dim_2” ]
},
“timestampSpec”: {
“format”: “auto”,
“column”: “timestamp”
}}},
“metricsSpec”: [
{
“type”: “longSum”,
“name”: “met_1”,
“fieldName”: “met_1”
}
]
}

``

And the partition spec:

“partitionsSpec”: {
“type”: “dimension”,
“partitionDimension”: “dim_1”
}

``

So the question is if Druid maintains secondary index?

When I need a grouping result filtered by some dim_1 value, besides timestamp, it knows on which historical nodes segment files with this value are, and doesn’t have to scan all segments within specific interval?

I do see the start and end values of dim_1 per shard in UI.

So if I have daily granularity and Druid knowns that shard_0 has values from a-c and shard_1 from d-z

and I am filtering by dim_1 with lower equals to a and upper to b will it scan only shard0?

Looks like there is, https://github.com/apache/incubator-druid/pull/2982, whether the pruning can be applied depends on the specific filter implementation being able to return a range of possible values for the dimension. (DimFilter#getDimensionRangeSet`)