A pg_statstabela revela que o PostgreSQL armazena um histograma ao coletar estatísticas. Isso significa que o PostgreSQL pode chegar a uma estimativa de quantas linhas um filtro retornará contando o número de buckets de histograma que contêm o valor do filtro. Você pode aumentar o número de buckets de histograma com o ALTER TABLE ... SET STATISTICSque significa que o PostgreSQL pode ser ainda mais preciso (estimar menos linhas) sobre a seletividade de um filtro.
O planejador de consulta estima a quantidade total de trabalho que precisa ser feito para executar a consulta e compara isso com um limite para ver se a compilação da consulta JIT deve ser feita. Essa estimativa inclui as estimativas de contagem de linhas que o PostgreSQL mantém para fins de seletividade de filtro? Aumentar o tamanho da amostra de estatísticas permitiria que o planejador de consultas tomasse melhores decisões sobre quando o benefício de desempenho da compilação JIT supera o tempo de inicialização da compilação JIT?
Estimativas mais precisas de contagens de linhas podem ser maiores ou menores do que a estimativa menos precisa. Se soubéssemos de antemão para qual caminho mais precisão iria, poderíamos (provavelmente) fazer algo para torná-lo mais preciso sem precisar de mais caixas de histograma.
Sim, as estimativas de contagem de linhas são uma parte importante da estimativa de custo total, e é isso que é comparado a jit_above_cost. Portanto, alterar a meta de estatísticas pode alterar a decisão do JIT, embora seja difícil prever com antecedência qual será a mudança. Por falar nisso, manter a meta de estatísticas igual e apenas refazer a amostra aleatória (por ANALISAR) também pode mudar a decisão.
Observe que jit_above_cost é uma heurística muito flexível em primeiro lugar. (E eu argumentaria um pouco errado - as estimativas de custo são frequentemente dominadas por estimativas de IO, e por que o tempo estimado de IO seria usado para decidir se deve ou não JIT? Isso não faz sentido, exceto no contexto em que as estimativas de custo são não sendo rastreado separadamente e não queremos mudar isso apenas para tornar jit_above_cost mais sensato)