1.

pelo que li, ele faz o hash da consulta e a mantém no banco de dados, salvando o texto no FS. Portanto, a próxima preocupação é mais esperada do que a memória compartilhada sobrecarregada:

o hash do texto é muito menor que o texto, que acho que você não deve se preocupar com o consumo de memória de extensão comparando consultas longas. Especialmente sabendo que a extensão usa o Query Analyzer (que funcionará para TODOS consulta QUALQUER MANEIRA ):

Configurando pg_stat_statements.max 10 vezes maior deve levar 10 vezes mais memória compartilhada, acredito. O crescimento deve ser linear . Não diz isso na documentação , mas logicamente deveria ser assim.

Não há resposta se é seguro ou não definir a configuração para um valor distinto, porque não há dados sobre outros valores de configuração e HW que você possui. Mas como o crescimento deve ser linear, considere esta resposta:"se você definir para 5K e o tempo de execução da consulta não tiver crescido quase nada, configurá-lo para 50K prolongará quase nada vezes dez". BTW, minha pergunta - quem vai cavar 50.000 declarações lentas? :)

2.

Esta extensão já faz uma pré-agregação para a declaração "desvalorizada". Você pode selecioná-lo diretamente no banco de dados, portanto, mover dados para outro banco de dados e selecioná-lo só lhe dará o benefício de descarregar o banco de dados original e carregar outro. Em outras palavras, você economiza 50 MB para uma consulta no original, mas gasta o mesmo em outro. Isso faz sentido? Para mim sim. Isso é o que eu mesmo faço. Mas também salvo planos de execução para instrução (que não faz parte da extensão pg_stat_statements). Eu acredito que depende do que você tem e do que você tem. Definitivamente, não há necessidade disso apenas por causa de uma série de consultas. Novamente, a menos que você tenha um arquivo tão grande que a extensão possa