Quando um índice columnstore seria inadequado para um ambiente OLAP com tabelas grandes e amplas?

Suponha que você recupere a maioria das linhas e das colunas.

Há alguma circunstância em que as condições acima se aplicam e um índice rowstore tradicional seria preferível a um índice columnstore, clusterizado ou não?

Os índices em geral não ajudam muito se você estiver selecionando a tabela inteira (ou perto dela, nas suas palavras acima), especialmente se você estiver selecionando as colunas conforme elas são armazenadas e não fazendo nenhum tipo de agregação , cálculos ou manipulações com eles.

Como você mencionou especificamente que este é um contexto OLAP, se você estiver fazendo algum tipo de agregação, um índice columnstore poderá beneficiá-lo pelo menos com a execução em modo lote :

A execução em modo lote é um método de processamento de consulta usado para processar várias linhas juntas. A execução em modo de lote está intimamente integrada e otimizada em torno do formato de armazenamento columnstore. A execução em modo lote às vezes é conhecida como execução baseada em vetor ou vetorizada. As consultas em índices columnstore usam a execução em modo lote, o que melhora o desempenho da consulta normalmente de duas a quatro vezes.

E, novamente, dado que a maioria das colunas será selecionada em suas consultas, você provavelmente desejaria agrupar seu índice columnstore. Dessa forma, a tabela original é mantida junta no columnstore, em vez de uma cópia dela ser mantida em um índice separado.

Consegui encontrar um caso em que o índice rowstore vence: quando você se preocupa com a exclusividade. Muitos tipos de junção, mas principalmente as junções de mesclagem, tornam-se muito mais rápidas quando sabem que ambos os lados das junções têm valores exclusivos. Um índice rowstore pode fornecer esse conhecimento com chaves primárias/exclusivas, mas os índices columnstore não podem oferecer isso.

Nos casos em que você tem um índice rowstore e um índice columnstore, acho que o otimizador geralmente escolherá o índice columnstore em vez do rowstore. Presumivelmente, ele estima corretamente que o índice columnstore será muito mais barato para verificar, mas conclui erroneamente que isso economizará mais esforço do que usar a exclusividade do índice rowstore.

Também há algo relevante sobre correspondências de hash, mas não tenho certeza do quê. Acho que uma junção de hash com um índice rowstore fará com que o predicado seja transmitido para a varredura do índice, mas uma junção de hash com um índice columnstore fará com que o filtro seja um operador explícito no plano de execução. Este último é muito mais lento.