On 06-03-2015 13:05, Luiz Carlos L. Nogueira Jr. wrote:
Olhando sua consulta, parece que você tem razão. Mas algo pode estar
errado (estatísticas desatualizadas, enable_indexscan desativado, você
se enganou com a PK, modelo de dados no banco não corresponde ao desenho
que você conhece, etc).
Pior que não.
CREATE TABLE core.tb_processo
(
id_processo id NOT NULL DEFAULT nextval('sq_tb_processo'::regclass),
-- Identificador do processo
nr_processo varchar30, -- Número do processo
nr_processo_origem varchar30, -- Número do processo de origem
ds_complemento varchar100, -- Descrição do complemento
dt_inicio data_hora NOT NULL, -- Data de início do processo
id_fluxo id, -- Identificador do fluxo
id_usuario_bloqueio id, -- Identificador do boqueio do usuário
id_usuario_cadastro_processo id, -- Identificador do usuário que
realizou o cadastro do processo
id_jbpm bigint, -- Identificador do ijpm
dt_fim data_hora, -- Data término do processo
nr_duracao bigint, -- Número da duração do processo
nm_actor_id client.varchar150,
id_caixa id,
id_status id,
ds_nm_usu_cadastro_processo client.varchar100,
nr_processo_temp varchar30, -- Número temporário do processo
CONSTRAINT sys_c005762 PRIMARY KEY (id_processo),
CONSTRAINT tb_processo_id_caixa_fkey FOREIGN KEY (id_caixa)
REFERENCES core.tb_caixa (id_caixa) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_processo_id_fluxo_fkey FOREIGN KEY (id_fluxo)
REFERENCES core.tb_fluxo (id_fluxo) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_processo_id_status_fkey FOREIGN KEY (id_status)
REFERENCES core.tb_status (id_status) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_processo_id_usuario_bloqueio_fkey FOREIGN KEY
(id_usuario_bloqueio)
REFERENCES core.tb_usuario (id_usuario) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT tb_processo_id_usuario_cadastro_processo_fkey FOREIGN KEY
(id_usuario_cadastro_processo)
REFERENCES core.tb_usuario (id_usuario) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
OIDS=FALSE
);
Faço o analyze todo final de semana
Normalmente não é necessário.
Esse post é semelhante ao que abri em 22/04/2014 com as mesmas
características.
É como se o print do log não tivesse sido feito na sequencia correta.
Isso ocorre várias vezes e com as mesmas características
A única coisa que poderia imaginar é que o temp é da transação e não do
statement, aí o PG tá se perdendo nesse meio, na hora de escrever no log
O temporário é sempre ligado a uma consulta.
Aí o PGBadger tá pegando o que está lendo e mostra a informação incorreta.
O PGBadger está correto, o que está estranho é o seu temporário.
Nada podemos fazer se você não nos mandar o resultado de:
EXPLAIN (analyze, buffers) SELECT...
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
