Por que o SQL Server se recusa a atualizar essas estatísticas com nada além de fullscan?

Percebi uma operação de estatísticas de atualização automática relativamente longa (20 min+) em uma compilação diária de datawarehouse. A tabela envolvida é

CREATE TABLE [dbo].[factWebAnalytics](
    [WebAnalyticsId] [bigint] IDENTITY(1,1) NOT NULL,
    [MarketKey] [int] NOT NULL CONSTRAINT [DF_factWebAnalytics_MarketKey]  DEFAULT ((-1)),
    /*Other columns removed*/
 CONSTRAINT [PK_factWebAnalytics] PRIMARY KEY CLUSTERED 
(
    [MarketKey] ASC,
    [WebAnalyticsId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [MarketKeyPS]([MarketKey])
) ON [MarketKeyPS]([MarketKey])

Isso está sendo executado no Microsoft SQL Server 2012 (SP1) - 11.0.3513.0 (X64), portanto, os índices columnstore graváveis ​​não estão disponíveis.

A tabela contém dados para duas chaves de mercado distintas. A compilação alterna a partição de um MarketKey específico para uma tabela de preparação, desativa o índice columnstore, executa as gravações necessárias, reconstrói o columnstore e o alterna novamente.

O plano de execução para as estatísticas de atualização mostra que ele extrai todas as linhas da tabela, as classifica, obtém o número estimado de linhas totalmente errado e se espalha para o tempdbnível de derramamento 2.

Corrida

SELECT [s].[name] AS "Statistic",
       [sp].*
FROM   [sys].[stats] AS [s]
       OUTER APPLY sys.dm_db_stats_properties ([s].[object_id], [s].[stats_id]) AS [sp]
WHERE  [s].[object_id] = OBJECT_ID(N'[dbo].[factWebAnalytics]'); 

shows

Se eu tentar explicitamente reduzir o tamanho da amostra das estatísticas desse índice para o usado pelos outros com

UPDATE STATISTICS [dbo].[factWebAnalytics] [PK_factWebAnalytics] WITH SAMPLE 897667 ROWS

A consulta é executada por mais de 20 minutos e o plano de execução mostra que está processando todas as linhas, não a amostra de 897.667 solicitada.

As estatísticas geradas no final de tudo isso não são muito interessantes e definitivamente não parecem justificar o tempo gasto em uma varredura completa.

Statistics for INDEX 'PK_factWebAnalytics'.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Name                            Updated                         Rows                            Rows Sampled                    Steps                           Density                         Average Key Length              String Index                    
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PK_factWebAnalytics             Jan 22 2016 11:31AM             420072086                       420072086                       2                               0                               12                              NO                                                              420072086                       

All Density                     Average Length                  Columns                         
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0.5                             4                               MarketKey                       
2.380544E-09                    12                              MarketKey, WebAnalyticsId       

Histogram Steps                 
RANGE_HI_KEY                    RANGE_ROWS                      EQ_ROWS                         DISTINCT_RANGE_ROWS             AVG_RANGE_ROWS                  
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1                               0                               3.441652E+08                    0                               1                               
2                               0                               7.590685E+07                    0                               1                               

Alguma ideia de por que estou encontrando esse comportamento e quais etapas posso seguir além de usá NORECOMPUTE-las?

Um script de reprodução está aqui . Ele simplesmente cria uma tabela com um PK clusterizado e um índice columnstore e tenta atualizar as estatísticas do PK com um tamanho de amostra baixo. Isso não usa particionamento - mostrando que o aspecto de particionamento não é necessário. No entanto, o uso do particionamento descrito acima torna as coisas piores, pois remover a partição e, em seguida, recuperá-la (mesmo sem nenhuma outra alteração) aumentará o modify_counter pelo dobro do número de linhas na partição, garantindo assim praticamente que as estatísticas serão considerado obsoleto e atualizado automaticamente.

Tentei adicionar um índice não clusterizado à tabela, conforme indicado em KB2986627 (ambos filtrados sem linhas e, quando isso falhou, um NCI não filtrado também sem efeito).

A reprodução não mostrou o comportamento problemático na compilação 11.0.6020.0 e, após a atualização para o SP3, o problema foi corrigido.