Com e sem seq_scan. O tempo não melhorou muito, mas o custo..
Hash Join (cost=22122.22..53155.35 rows=724909 width=8) (actual
time=848.384..2502.618 rows=724909 loops=1)
Hash Cond: ((ppe.id_processo_expediente)::integer =
(pe.id_processo_expediente)::integer)
- Seq Scan on
SET enable_seqscan TO on;
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
FROM tb_proc_parte_expediente ppe
where exists (select 1 from tb_processo_expediente pe where
pe.id_processo_expediente::integer =
Teria como criar uma view dessa query pra ser sempre usada com o seq_scan
off?
2015-03-20 8:34 GMT-03:00 Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com:
SET enable_seqscan TO on;
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
Aquilo ali é um pedaço de uma view que usa union com outro select.
Aí estava analisando parte a parte e cheguei nesse ponto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
Não tem nada haver com estatística; a questão é IO. Ele quer trazer
~700k registros em um tempo pequeno. Melhorar isso só com IO mais rápida.
Não vejo como tal consulta pode ser utilizada numa aplicação; a não ser
que seja em um relatório. Você esqueceu uma condição ali, não?
Aquilo ali é um
2015-03-20 9:48 GMT-03:00 Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com:
Aquilo ali é um pedaço de uma view que usa union com outro select.
Aí estava analisando parte a parte e cheguei nesse ponto
UNION ou UNION ALL?
Talvez você devesse analisar como um todo, pode ser que tenha outras
On Fri, Mar 20, 2015 at 8:34 AM, Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com wrote:
SET enable_seqscan TO on;
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
FROM tb_proc_parte_expediente ppe
where exists (select 1 from
UNION ou UNION ALL?
UNION ALL
Talvez você devesse analisar como um todo, pode ser que tenha outras
maneiras de melhorar a performance.
É, Tô vendo as querys que usam essa view pra ver se tem como melhorar.
Em 20 de março de 2015 09:55, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
Le 20 mars 2015 08:36:55 GMT-03:00, Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com a écrit :
Teria como criar uma view dessa query pra ser sempre usada com o
seq_scan off?
O ideal é resolver a causa. Geralmente, estatísticas desatualizadas.
--
skype:leandro.gfc.dutra?chat Yahoo!:
On 20-03-2015 08:54, Leandro Guimarães Faria Corcete DUTRA wrote:
Le 20 mars 2015 08:36:55 GMT-03:00, Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com a écrit :
Teria como criar uma view dessa query pra ser sempre usada com o
seq_scan off?
O ideal é resolver a causa. Geralmente,
2015-03-19 16:38 GMT-03:00 Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com:
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
FROM tb_proc_parte_expediente ppe
JOIN tb_processo_expediente pe ON ppe.id_processo_expediente::integer =
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
FROM tb_proc_parte_expediente ppe
JOIN tb_processo_expediente pe ON ppe.id_processo_expediente::integer =
pe.id_processo_expediente::integer
Hash Join (cost=22106.25..53111.83 rows=724368
Em 19 de março de 2015 14:49, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
2015-03-19 16:38 GMT-03:00 Luiz Carlos L. Nogueira Jr.
lcnogueir...@gmail.com:
explain analyze
SELECT ppe.id_processo_parte_expediente,
ppe.id_pessoa_parte AS id_destinatario
FROM
13 matches
Mail list logo
