2013/6/28 Douglas Fabiano Specht <[email protected]> > > > > 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. >>> >>> > 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? >
Pelo modelo MVCC do PostgreSQL um UPDATE nada mais é do que um INSERT+DELETE (é mais, mas vamos simplificar, ok?). Logo, se a tabela tiver muitos campos, atualizar qualquer um deles fará com que haja uma cópia de outros (não necessariamente todos, há exceções), o que explica o comportamento observado em #2. Além disso, ao inserir novos registros, tem que atualizar também os índices, o que explica o comportamento observando em #1. Há duas melhorias nesse caso: 1. Diminuir o fillfactor da tabela, fazendo que atualizações "possam" ocorrer na mesma página, e não necessitando a atualização dos índices. **MAS**, isso vai causar um maior inchaço nas tabelas, o que, na minha opinião, é ruim para uma operação não frequente. 2. Deletar todos os índices, fazer a atualização e recriar novamente. Veja [1] para mais dicas semelhantes. > 3- quando faço esse update fisicamente ele altera todos os blocos da > tabela toda? > > > Depende da consulta, se não tem WHERE ou casar com tudo é o que vai acontecer. [1] http://www.postgresql.org/docs/current/static/populate.html Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
