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?
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).
Considere o uso da extensão auto explain por um tempo e verificar se o
plano não mudou justamente naquele momento.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
