Fazer diagnostico do que é possivel para reduzir os custos da query de where para tabelas muito grandes
Tabelas grandes devem ter colunas utilizadas no config where para filtrar a data mais recente como Partições e/ou Clusters para reduzir o custo das queries de teste. As partições indicam como os dados são distribuidos no BQ e seu bom uso é o mecanismo mais simples de garantir eficiência nas queries.
Possível problema: partições só são de fato utilizadas no BQ quando os filtros são feitos com valores constantes. No caso de subqueries as partições são ignoradas. A Macro custom_get_where_subquery, como o nome sugere, usa uma subgquery
Solução: modificar | criar uma macro que use uma CTE com filtros constantes no lugar de uma SUBQUERY
Configurar cache de queries feitas nos testes para reduzir o custos de testes sucessivos
Qual é o maior gargalo de custo de processamento? Do ponto de vista dos testes, quais testes e quais tabelas?
Este ponto vai além do definido nessa issue por se tratar do monitoramente de custos de processamento como um todo. Todavia, entender o custo a nível de flows/modelos é o caminho para uma gerência eficiente do sistema.
Fazer diagnostico do que é possivel para reduzir os custos da query de where para tabelas muito grandes
Tabelas grandes devem ter colunas utilizadas no config where para filtrar a data mais recente como Partições e/ou Clusters para reduzir o custo das queries de teste. As partições indicam como os dados são distribuidos no BQ e seu bom uso é o mecanismo mais simples de garantir eficiência nas queries.
Configurar cache de queries feitas nos testes para reduzir o custos de testes sucessivos
Qual é o maior gargalo de custo de processamento? Do ponto de vista dos testes, quais testes e quais tabelas?