A causa da lentidão são as estimativas de contagem de linhas incorretas que fazem o PostgreSQL escolher uma junção de loop aninhado. Quase todo o seu tempo é gasto na verificação do índice em
hfj_res_link
, que é repetido 1113 vezes. Minha primeira tentativa seria
ANALYZE hfj_spidx_date
e veja se isso ajuda. Se sim, certifique-se de que o autoanalyze trata essa tabela com mais frequência. A próxima tentativa seria
SET default_statistics_target = 1000;
e então
ANALYZE
como acima. Se isso ajudar, use ALTER TABLE
para aumentar as STATISTICS
na hash_identity
e sp_value_high
colunas. Se isso também não ajudar e você tiver uma versão recente do PostgreSQL, tente estatísticas estendidas :
CREATE STATISTICS myparamsda2_stats (dependencies)
ON hash_identity, sp_value_high FROM hfj_spidx_date;
Então
ANALYZE
a tabela novamente e veja se isso ajuda. Se tudo isso não ajudar e você não conseguir obter as estimativas corretas, tente um ângulo diferente:
CREATE INDEX ON hfj_res_link (target_resource_id, src_resource_id);
Isso deve acelerar consideravelmente a verificação do índice e fornecer bons tempos de resposta.
Finalmente, se nenhuma das opções acima tiver algum efeito, você pode usar a medida crua de não permitir junções de loop aninhado para esta consulta:
BEGIN;
SET LOCAL enable_nestloop = off;
SELECT /* your query goes here */;
COMMIT;