Hi Brad,
No, the query isn't trying to select specific rows; it's aggregating data with some GROUP BY logic - it's a fact table in a data warehouse with 35M rows, and the columnstore works quite nicely for our purposes. A little more background on this specific scenario: we currently have the fact table partitioned on column A, and we're thinking of changing the partition key to a different column to accommodate a future business requirement. I've been testing the 2 partition schemes in an isolated development environment to see how query performance is impacted. For these tests, there is no fragmentation or anything like that - the CS index is built fresh, so no delta store and no deletes.
One of the test results was puzzling to me - I thought I would see a performance increase with our new partition key (call this P2) due to partition elimination, but it actually performs worse than the original partition setup (call this P1). I do see partition elimination, so that is behaving as expected. Also, the Query plans are very similar. However, I noticed that the LOB reads are much higher with P2 than they were with P1. It turns out that P2 has many more segments being read than P1 did. I looked into why that was, and noticed that P2 has a lot of segments that are trimmed in each partition. And I'm not sure why. I think this is the cause for the increased query time, but not sure.
Hope that helps to clarify. Yes, I reference Niko's blog quite a bit as I work through CS issues - his work is invaluable!