Em 27 de junho de 2013 12:28, Marcelo Henrique Gonçalves <[email protected] > escreveu:
> Seu problema não parece de tuning da instância PostgreSQL e sim de > arquitetura. > Estude redução dos índices, melhor where clause para o update, FKs que > apontam para a PK dessa, etc... > > > 2013/6/27 Douglas Fabiano Specht <[email protected]> > >> >> >> Em 26 de junho de 2013 15:06, Marcelo Henrique Gonçalves < >> [email protected]> escreveu: >> >>> Depende, todos ou quase nenhum. >>> >>> È necessário ter uma noção: >>> >>> a) Banco OLTP ou DW? >>> b) Número de updates por segundo, usará índice na busca pela linha? >>> c) Número aproximado de transações / segundo no banco >>> d) Tamanho da tabela, e do índice >>> e) Tamanho da memória da máquina (justificativa para 1GB de >>> shared_buffer). >>> >>> Mostrar o explain do udpate, ajuda. Você precisa saber a frequência de >>> commit do seu banco... >>> >>> >>> _______________________________________________ >>> pgbr-geral mailing list >>> [email protected] >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >> Bom dia Pessoal, >> essa tabela tem uns 100 campos e umas 8 fk e 9 indices. >> >> segue as informações, >> explain: >> >> "Update on lanccaixa (cost=0.00..197881.30 rows=7166 width=633) (actual >> time=1012846.965..1012846.965 rows=0 loops=1)" >> " -> Seq Scan on lanccaixa (cost=0.00..197881.30 rows=7166 width=633) >> (actual time=25.047..58396.786 rows=1413418 loops=1)" >> " Filter: (flindpag IS NULL)" >> "Trigger for constraint fkdocfiscalser: time=66582.215 calls=1413418" >> "Trigger for constraint fklanccaixaconcor: time=5596.281 calls=1413418" >> "Trigger for constraint fklanccaixaplacon: time=5586.670 calls=1413418" >> "Trigger for constraint fklanccxadocfiscal: time=5274.534 calls=1366084" >> "Trigger for constraint fklanccxcdcentro: time=5480.920 calls=1413418" >> "Trigger for constraint fklanccxhistlanccre: time=5467.979 calls=1413418" >> "Trigger for constraint fklanccxhistlancdeb: time=5400.965 calls=1413418" >> "Trigger for constraint fklcxacdadiant: time=5418.880 calls=1413418" >> "Total runtime: 1119142.220 ms" >> >> >> a) Banco OLTP ou DW? >> OLTP >> b) Número de updates por segundo, usará índice na busca pela linha? >> esse update é num troca versao de aplicativo, ou seja so será executado >> uma unica vez, em cada cliente. Nao utilizara indice na busca. >> >> c) Número aproximado de transações / segundo no banco >> d) Tamanho da tabela, e do índice >> tamanho da tabela, "lanccaixa";"1434 MB"; com indices: "3010 MB" >> >> e) Tamanho da memória da máquina (justificativa para 1GB de >> shared_buffer). >> 4gb, mas é windows. >> >> -- >> >> Douglas Fabiano Specht >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > Marcelo Henrique Gonçalves > +55 19 8828 7958 > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > bom dia Pessoal, estive analisando e testando alguns updates, e pude verificar que se deixar a tabela com 50 campos, a performance do update melhora em de uns 20min para 7min. dropando os indices melhora mais ainda, neste caso me leva a algumas questoes: 1- esse campo não participa de nenhum indice, mas por que dropando os outros ele melhora no desempenho? 2- tabelas com menos campos tem melhor desempenho mesmo com a mesma quantidade de registros? 3- quando faço esse update fisicamente ele altera todos os blocos da tabela toda? -- Douglas Fabiano Specht
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
