2014-04-22 18:26 GMT-03:00 Luiz Carlos L. Nogueira Jr. < [email protected]>:
> 22.12 MiB > SELECT processo0_.id_processo AS id1_488_0_, processo0_.nm_actor_id > ASnm2_488_0_ > , processo0_.id_caixa AS id11_488_0_, processo0_.ds_complemento ASds3_488_0_ > , processo0_.dt_fim AS dt4_488_0_, processo0_.dt_inicio AS > dt5_488_0_,processo0_ > .nr_duracao AS nr6_488_0_, processo0_.id_fluxo AS id12_488_0_, > processo0_.id_jbpm > AS id7_488_0_, processo0_.ds_nm_usu_cadastro_processo AS ds8_488_0_,processo0_ > .nr_processo AS nr9_488_0_, processo0_.nr_processo_origem AS > nr10_488_0_,processo0_ > .id_status AS id13_488_0_, processo0_.id_usuario_cadastro_processo > ASid14_488_0_ > FROM tb_processo processo0_ WHERE processo0_.id_processo = $1; > > > Essa tabela tb_processo tem pk com o campo id_processo. > A tabela tem 17MB de dados e 36MB de índices, com 190000 live tuples. > > Como pode ter dado esses 22MB de temp files? Não tem joins, está indo pela > PK, não tem campo blob, etc Poderia executar um EXPLAIN (ANALYZE,VERBOSE,BUFFERS) dessa query e postar aqui (ou em [1]) o resultado? Aliás, deveria executá-la direto e também com um PREPARED STATEMENT. Não me parece que tal consulta deveria ser executado de outra forma que não um index-scan. Também temos que considerar um possível bug no pgbadger ao processar as linhas do log, mas terias de ver (grep) os logs reais para confirmar. [1] http://explain.depesz.com/ 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
