On 25-04-2014 08:38, Flavio Henrique Araque Gurgel wrote: >> Apareceu de novo, e com um temp file maior ainda >> >> 67.82 MiB >> SELECT processo0_.id_processo AS id1_278_0_, processo0_.nm_actor_id AS >> nm2_278_0_, processo0_.id_caixa AS id11_278_0_, >> processo0_.ds_complemento AS ds3_278_0_, processo0_.dt_fim AS >> dt4_278_0_, processo0_.dt_inicio AS dt5_278_0_, processo0_.nr_duracao AS >> nr6_278_0_, processo0_.id_fluxo AS id12_278_0_, processo0_.id_jbpm AS >> id7_278_0_, processo0_.ds_nm_usu_cadastro_processo AS ds8_278_0_, >> processo0_.nr_processo AS nr9_278_0_, processo0_.nr_processo_origem AS >> nr10_278_0_, processo0_.id_status AS id13_278_0_, >> processo0_.id_usuario_cadastro_processo AS id14_278_0_ FROM tb_processo >> processo0_ WHERE processo0_.id_processo = $1; >> >> Isso é maior que toda a tabela + os índices. >> >> MUITO ESTRANHO!!!!! > > Qual a versão exata do PostgreSQL? >
Ele está usando a 9.3.4. > id_processo é mesmo a PK? O uso de parâmetros pode fazer isso e o > planejador não tem como determinar o plano ótimo (típico da dupla jdbc + > Hibernate). > Pelo que conheço do PJE essa coluna "id_processo" é sim PK da "tb_processo". O que pode estar ocorrendo é aquele $1 estar sendo substituido por algo do tipo '0 or 1=1' e dai vai levar a um seqscan em toda tabela. > Considere o uso da extensão auto explain por um tempo e verificar se o > plano não mudou justamente naquele momento. > Faça isso Luiz e nos informe o plano quando ocorrer novamente a geração de 'temp files'. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
