>> Isto que você está lendo é um top post. >> Por favor, não faça como eu fiz aqui.
>> Veja que coloquei suas respostas quotadas abaixo. >> Ah, também, por favor, coloque um assunto mais relacionado à sua >> pergunta. Simplesmente "Consultoria PostgreSQL" soa péssimo em vários >> sentidos, quem vai te ajudar vai começar lendo pelo assunto. > Realmente, me precipitei no Assunto... > Desculpe me Tudo bem, a gente perdoa :) UMA VEZ! :D O que eu tô achando legal é que meu novo exemplo sobre como *não* fazer top posting tem funcionado já na segunda resposta. >> Esse valor dá mais de 300 MiB de memória para um simples SELECT que >> precise disso. >> Você falou que a função é que está lenta. >> Já verificou se sua memória não se esgotou justamente na hora de >> executar a função? É um cenário que você pode reproduzir. > Sim, ja verifiquei e a memória não se esgota.. Uhm, ok. Como fez, usou free? >>> Tenho em media 100 conexoes simultaneas.. Os principais parametros estao >>> setados para: >>> shared_buffers = 128000 >>1 GiB só aqui. >>Quanto de memória você tem e qual o parâmetro max_connections? > No servidor tenho 16GB de memória. em max_connections tenho 250 Olha só, sei que você não observou falta de memória, mas faça a conta: 300 MiB * 250 = mais de 70 GiB !!! Você está correndo o risco de ficar sem memória a qualquer momento! Isso que subselects (não sei quais consultas você faz) pode usar o "sort_mem" mais de uma vez. Mas, vamos lá, você não observou falta de memória, então: O que sua função faz? Infelizmente é o único jeito de saber porque ela é lenta. []s __________________________________ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos & Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br ______________________________ FREE SOFTWARE SOLUTIONS _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
