Amanha mesmo, estarei testando... muito obrigado Mozart
Em 21 de junho de 2010 22:52, Mozart Hasse mozart.ha...@usa.net escreveu:
Olá Eduardo,
Depois de ler a técnica tentei de todo jeito mas não fui muito feliz...
Vamos mudar o placar então.
Não conheço a regra de negócio dessas
Mozar,
Depois de ler a técnica tentei de todo jeito mas não fui muito feliz...
A 1 Parte com Inner, ficou muito RAPIDO
Acho que fiz errado , na segunda parte pq piorou o tempo da query
anterior
essa é a query
(ja tomei de uns 8x0 dela)
---
SELECT
Jun 2010 15:45:13 -0300
From: Eduardo Amaral edu.ama...@gmail.com
Subject: Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
To: Comunidade PostgreSQL Brasileira
pgbr-geral@listas.postgresql.org.br
Message-ID:
aanlktikzriyse06s0wmj31j9bde6cd35ujekno_6o...@mail.gmail.com
Content-Type: text/plain
Olá Eduardo,
Depois de ler a técnica tentei de todo jeito mas não fui muito feliz...
Vamos mudar o placar então.
Não conheço a regra de negócio dessas tabelas, mas pelo que entendi são
duas
subconsultas independentes, sendo assim, vejamos:
* o segundo UNION não pode ter os INNER que você
Oi Marcel,
Não ficou muito claro para mim a reescrita de uma consulta.
Como eu faria numa consulta como esta abaixo???
*Assumindo* que turmas_ofertas_professores tem o campo turma_oferta_id não
nulo
*e* que *todo* o professor tem uma referência à tabela pessoas, ficaria:
SELECT tof.id AS
Aham, muito obrigado pela explicação. Irei testar daqui a pouco e darei
retorno.
--
Abraços..
Marcel Araujo
System Analyst
Developer Java/PHP/RIA
Linux User #490101
http://br.linkedin.com/in/marcelaraujo
http://www.twitter.com/marcelaraujo
http://marcelaraujo.tumblr.com/
ahahahahaha, tô em estado de graça!
Meu amigo, consegui reduzir uma consulta de faturamento de 67 segundos para
apenas 10 segundos e podendo melhor ainda mais.
--
Abraços..
Marcel Araujo
System Analyst
Developer Java/PHP/RIA
Linux User #490101
http://br.linkedin.com/in/marcelaraujo
Olá Mozart,
estava tentando reescrever uma consulta agora a pouco, tentando aplicar
essas sugestões.
Porém, se eu executasse desse jeito que está no exemplo, ele não reclamaria
que está faltando entrada para a tabela ps e pf no segundo select? E se eu
colocasse os inners para essas tabelas não
Oi Priscila,
Subject: Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
To: Comunidade PostgreSQL Brasileira
Porém, se eu executasse desse jeito que está no exemplo, ele não
reclamaria
que está faltando entrada para a tabela ps e pf no segundo select? E se eu
colocasse os inners para essas
= b.id)
UNION all
-- com B com C
SELECT campoA, campoB, campoC as c FROM a
INNER JOIN b ON (a.id= b.id)
INNER JOIN c ON (a.id= c.id)
Mozart
-- Original Message --
From: mateusgra mateus...@bol.com.br
Subject: Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
Seria assim:
SELECT
)
INNER JOIN c ON (a.id= c.id)
Mozart
-- Original Message --
From: mateusgramateus...@bol.com.br
Subject: Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
Seria assim:
SELECT campoA, campoB, null as c FROM a INNER JOIN b ON (a.id= b.id)
UNION all
SELECT campoA, null as b
Sim amigo por exemplo a query que estava tentando melhorar demorava
uns 25segundos com left join passando a usar a técnica do Mozart ela
passou a executar em no max 3segundos.
Abaixo segue a query modificada.
SELECT
codigofab,
descricao,
prazo,
quantidade,
Aplique a idéia de usar UNION ALL. Isso funciona em qualquer servidor SQL e
nunca vi piorar o desempenho da consulta. O que faço é o seguinte: para
CADA
LEF OUTER JOIN da sua consulta, substitua por duas cópias da mesma query
separadas por UNION ALL (não union, tem de ser UNION ALL), sendo
Benedito,
Não sei se minha pergunta é boba, mas:
Porque fazer desse jeito é mais eficiente do que fazer um LEFT JOIN?
A pergunta não é boba não, na realidade a explicação não é nada trivial.
A resposta mais simples e curta que posso dar é: esse jeito (UNION ALL +
INNER + NOT EXISTS) é
Muito boa explicação, obrigado!
Em 19/05/2010 19:55, Mozart Hasse escreveu:
Benedito,
Não sei se minha pergunta é boba, mas:
Porque fazer desse jeito é mais eficiente do que fazer um LEFT JOIN?
A pergunta não é boba não, na realidade a explicação não é nada trivial.
A
Não ficou muito claro para mim a reescrita de uma consulta.
Como eu faria numa consulta como esta abaixo???
*CREATE OR REPLACE VIEW vw_ch_professores_turmas_ofertas AS
SELECT tof.id AS turma_oferta_id, tpo.id AS turma_professor_id, pf.id AS
professor_id, pf.cod_prof, ps.id, ps.nome_pessoa,
Obrigado pelas dicas tanto a do Marcos que faz pensar que quando
iniciar um projeto novo já planejar essas functions e a solução do
Mozart que implementei e deu certo a query demorava 25segundos caiu
para 2 3 segundos.
vlw...
Att
Vinicius Perroni
___
consulta com LEFT JOIN
Estou com um velho problema uma consulta minha utiliza muitos LEFT
JOINS tornandoa lenta demais.
A consulta é mais ou menos assim tenho uma tabela de orçamentos, uma
de ordens de compras e outra de Notas Fiscas, três tabelas sendo o
unico registro que certamente existe
tem registro so em A e C ou A e
B.
Mozart Hasse wrote:
Olá Vinicius,
From: vinicius perroni vinicius...@gmail.com
Subject: [pgbr-geral] Otimizar consulta com LEFT JOIN
Estou com um velho problema uma consulta minha utiliza muitos LEFT
JOINS tornandoa lenta demais.
A consulta é
Bom dia a todos.
Estou com um velho problema uma consulta minha utiliza muitos LEFT
JOINS tornandoa lenta demais.
A consulta é mais ou menos assim tenho uma tabela de orçamentos, uma
de ordens de compras e outra de Notas Fiscas, três tabelas sendo o
unico registro que certamente existe é o
Obrigado é um boa alternativa esta sua. (Só não sei se meu chefe vai
deixar eu sair criando funções na base de dados hehehe mas isso é
outro problema)
Obrigado pela ajuda.
Em 17 de maio de 2010 11:27, Marcos - GMail lgerardlu...@gmail.com escreveu:
Tu pode fazer o seguinte: Se eu entendi bem,
Olá Vinicius,
From: vinicius perroni vinicius...@gmail.com
Subject: [pgbr-geral] Otimizar consulta com LEFT JOIN
Estou com um velho problema uma consulta minha utiliza muitos LEFT
JOINS tornandoa lenta demais.
A consulta é mais ou menos assim tenho uma tabela de orçamentos, uma
de ordens
22 matches
Mail list logo
