Em primeiro lugar, estes são dois modelos de dados diferentes adequados para diferentes propósitos.

Dito isto, eu esperaria que o segundo modelo fosse mais rápido para agregação, simplesmente porque os dados são empacotados de forma mais compacta, portanto, precisando de menos E/S:

• O GROUP BY no primeiro modelo pode ser satisfeito por um completo digitalizar no índice {size, price} . A alternativa para indexar é muito lenta quando os dados são muito grandes para caber na RAM.
• A consulta no segundo modelo pode ser satisfeita por uma verificação completa da tabela. Não é necessário índice.

Como a primeira abordagem requer tabela + índice e a segunda apenas a tabela, a utilização do cache é melhor no segundo caso. Mesmo se desconsiderarmos o cache e compararmos o índice (sem tabela) no primeiro modelo com a tabela no segundo modelo, suspeito que o índice será maior que a tabela, simplesmente porque ele registra fisicamente o size e tem "buracos" não utilizados típicos para B-Trees (embora o mesmo seja verdade para a tabela se for agrupado ).

E, finalmente, o segundo modelo não tem a sobrecarga de manutenção do índice, o que pode afetar o desempenho de INSERT/UPDATE/DELETE.

Fora isso, você pode considerar armazenar em cache SUM e COUNT em uma tabela separada contendo apenas uma linha. Atualize SUM e COUNT por meio de gatilhos sempre que uma linha for inserida, atualizada ou excluída na tabela principal. Você pode obter facilmente o AVG atual, simplesmente dividindo SUM e COUNT.

Mas você deve realmente medir em quantidades representativas de dados para ter certeza.

Como não há cláusula WHERE em sua consulta, todas as linhas serão verificadas. Os índices são úteis apenas para obter um subconjunto relativamente pequeno de linhas da tabela (e às vezes para varreduras somente de índice ). Como regra geral, se mais de 10% das linhas da tabela forem necessárias, os índices não ajudarão e o DBMS geralmente optará por uma verificação completa da tabela, mesmo quando os índices estiverem disponíveis.