Complementando, verifique se tabelas mais lentas estão nas mesmas tablespaces que as mais rápidas, veja também o número de índices que esta tabelas possuem. SELECT "*" é o PIOR plano de execução que o KERNEL pode executar, opte sempre por SELECT CAMPO1,2,3,4,...N. Caso use a clausura WHERE pririze-a INVERTENTO a ordem dos campos EXE:- WHERE CAMPO4,3,2,1.
T+ Seja Livre! Use OpenSource! LineOn, Tecnologia da Informação! http://lineonti.wordpress.com Em 15 de julho de 2013 21:28, Flavio Henrique Araque Gurgel < [email protected]> escreveu: > > Algumas tabelas do meu banco acabam sendo mais lentas para abrir do > outras, o > > que pode ser? > > Vários fatores. > > > Sei que muito coisa pode influenciar em ralação a hardware e > configuração, > > mas uma tabela ser "melhor" que outra ainda não tinha visto. > > Por exemplo, tenho a tabela de clientes com media de 5mil registros num > > select * from tabela, sem nenhum filtro ele demora 1617ms para abrir, já > > outra tabela com 103 registros demora 3927ms > > > > Como pode isso ? > > Um dos argumentos abaixo: > 1) Como as tabelas são pequenas, o uso de cache influencia muito o > desempenho de um select sem parâmetros como o seu. Uma tabela pode estar > inteiramente em cache e ser lida muito rapidamente. > 2) O que importa não é o número de linhas (ou registros, se preferir) mas > quantos bytes são retornados. Uma única linha num bytea de 500 MiB vai > demorar 500 vezes mais para ser lida do disco do que uma linha de 5 MiB. > 3) Inchaço (bloat) da tabela. Uma tabela com centenas de updates e vai ter > mais espaço ocupado em disco, obrigando a fazer muito I/O. Logo, um select > nela vai demorar mais. > > > Meu servidor deve estar com problema de "balanceamento", rs ? > > Observando ambas as tabelas não existe nada de extraordinário entre elas, > > ambas foram criadas do mesmo modo e seus indices são somente em campos > mais > > utilizados em selects, porem meus testes foram em select simples, sem > > filtro. > > > > Não estou entendendo porque a lentidão em apenas algumas tabelas. (com > poucos > > registros) > > Nada a ver. Desencana, isso é normal. Um teste desses em tabelas pequenas > vai apresentar o comportamente que você está vendo. Se você repetir os > mesmos selects após limpar o cache do S.O. e reiniciar o PostgreSQL vai dar > números completamente diferentes. E, se repetir a consulta diversas vezes, > também. > > Mande-nos um explain analyze de seus SELECTs e dará pra ver direitinho o > custo de cada uma delas. > > []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: [email protected] > ______________________________ > FREE SOFTWARE SOLUTIONS > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
