Even SQL Server doesn't use `min_data_id` or `max_data_id` directly when processing `MIN` or `MAX` aggregates, even when [aggregate pushdown][1] (SQL Server 2016 or later, Enterprise Edition or equivalent) is employed. Every row in qualifying buckets is processed, albeit using an efficient SIMD implementation. To illustrate, the following stack trace was obtained on SQL Server 2022: [![Pushed down aggregate stack trace][2]][2] This doesn't *necessarily* mean the metadata is unreliable, though it could be if the deleted bitmap is non-empty since the min or max row might be logically deleted. There is also the question of which rows are visible to the current transaction given the current isolation level. Whatever the exact reasons, the fact remains that SQL Server itself does not employ this potential optimisation. You could decide that approximate results are good enough for your needs. Perhaps you know delta stores and the deleted bitmap will always be empty. You'll still need to decode the `bigint` values of `min_data_id` and `max_data_id` to the target data type when *value-based* encoding is used. When *hash-based* encoding is used with a dictionary, you're simply out of luck. There's no way supported way to access the dictionary from T-SQL, much less a way to decode a particular value to a correctly typed dictionary entry. In your position, I would be more concerned with getting the best possible *supported* performance for your `MIN` and `MAX` aggregates. Aggregate pushdown is a must, but that does depend on the data types in use and your version and edition of SQL Server, among other factors. You would start by looking for the *Actual Number of Locally Aggregated Rows* on the columnstore scan in a post-execution ('actual') execution plan. Beyond that, you would look into the amount of physical I/O involved and sizing of the columnstore memory pool, along with CPU utilisation. Under ideal conditions, SQL Server is capable of extremely good aggregate performance on columnstore data. [1]: https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-query-performance#aggregate-pushdown [2]: https://i.sstatic.net/2hFH8rM6.png