Segue a análise da query: http://explain.depesz.com/s/8PN
PS: Muito bom esse explain.depesz.com. Sou novo em Postgres, por isso não conhecia. Também estou me adaptando com o formato desta lista. Aceito dicas. Flavio Yamil Gómez Diretor - Meta Virtual Fone: (47) 3268 1780 Skype: flavio_yamil Em 17 de janeiro de 2013 10:54, <[email protected] > escreveu: > Send pgbr-geral mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pgbr-geral digest..." > > > Tópicos de Hoje: > > 1. TRIGGER a disparar só com base num atributo (Pedro Costa) > 2. Re: TRIGGER a disparar só com base num atributo (Anselmo Silva) > 3. Re: View com union - Muito lenta (Matheus de Oliveira) > 4. Problemas com Data. (Fabio Ebner) > 5. Re: Problemas com Data. (Fábio Telles Rodriguez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Jan 2013 12:22:48 +0000 > From: Pedro Costa <[email protected]> > Subject: [pgbr-geral] TRIGGER a disparar só com base num atributo > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Olá pessoal, > > Alguém sabe se é possível implementar um trigger que dispara com um > UPDATE mas só num determinado campo? > > versão do postgresql: 9.1.4 > > > Obrigado > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Jan 2013 09:35:11 -0300 > From: Anselmo Silva <[email protected]> > Subject: Re: [pgbr-geral] TRIGGER a disparar só com base num atributo > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > <CAFE0_FVdpOA7+Yzgxq07mNzUHnrcx3cdCU33= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > Alguém sabe se é possível implementar um trigger que dispara com um > > UPDATE mas só num determinado campo? > > > > versão do postgresql: 9.1.4 > > > > na trigger coloque UPDATE OF [COLUNA] (irá disparar apenas se for > atualizado essa coluna) > > -- > Anselmo M. Silva > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130117/35075940/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Thu, 17 Jan 2013 10:35:22 -0200 > From: Matheus de Oliveira <[email protected]> > Subject: Re: [pgbr-geral] View com union - Muito lenta > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > <CAJghg4Ko2HgZtxhn4ykgOJd6+Ov6j8MTHyzzaPSZ= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > 2013/1/17 Flavio Yamil Gómez <[email protected]> > > > Olá colegas, > > > > Segue abaixo exemplo de query que estou executando (Query 1). Vejam que > > ela faz um "Seq Scan" na tabela de cidades (2,6 milhões de registros) e > > demora 4000ms para executar. > > > > A QUERY 2 faz um "Index Scan" e demora 17ms para executar e é exatamente > > igual à QUERY 1, exceto o segundo join que foi alterado de: > > > > left join vw_loc_origem_destino2 on vw_loc_origem_destino2.cd_codigo = > > com_trafego.cd_origem_carga > > > > Para: > > > > left join vw_loc_origem_destino2 on vw_loc_origem_destino2.cd_codigo = > 99 > > > > > > Pra mim as duas consultas são *completamente* distintas. Na primeira o > PostgreSQL tem que realizar uma junção, que, muitas vezes, é mais rápido > com seq-scan do que com index-scan. > > Não é difícil entender o porquê. Pense no modelo de junção mais simples, o > banco terá que navegar em uma tabela para buscar valores iguais na outra, > ou seja, não estaria buscando somente por um único registro da tabela, mas > sim vários. > > > > > Seguem as queries: > > > > ** QUERY 1 ** > > select > > com_oferta.cd_oferta > > from > > com_oferta > > left join com_trafego on com_trafego.cd_oferta = com_oferta.cd_oferta > > left join vw_loc_origem_destino2 on vw_loc_origem_destino2.cd_codigo = > > com_trafego.cd_origem_carga > > where > > com_oferta.nr_oferta = 42 > > > > Analyze da QUERY1: > > > > "Merge Right Join (cost=532877.64..606356.25 rows=26575 width=4)" > > " Merge Cond: (loc_cidade.cd_cidade = com_trafego.cd_origem_carga)" > > " -> Unique (cost=532873.86..572735.67 rows=2657454 width=22)" > > " -> Sort (cost=532873.86..539517.49 rows=2657454 width=22)" > > " Sort Key: loc_cidade.cd_cidade, > > ((loc_cidade.nm_cidade)::text), loc_cidade.cd_pais, loc_cidade.cd_regiao, > > (3)" > > " -> Append (cost=0.00..85796.08 rows=2657454 width=22)" > > " -> Seq Scan on loc_cidade (cost=0.00..59220.51 > > rows=2657451 width=22)" > > " -> Seq Scan on loc_porto (cost=0.00..1.03 rows=3 > > width=226)" > > " -> Sort (cost=3.78..3.79 rows=2 width=8)" > > " Sort Key: com_trafego.cd_origem_carga" > > " -> Hash Left Join (cost=2.10..3.77 rows=2 width=8)" > > " Hash Cond: (com_oferta.cd_oferta = com_trafego.cd_oferta)" > > " -> Seq Scan on com_oferta (cost=0.00..1.63 rows=2 > > width=4)" > > " Filter: (nr_oferta = 42)" > > " -> Hash (cost=1.49..1.49 rows=49 width=8)" > > " -> Seq Scan on com_trafego (cost=0.00..1.49 > rows=49 > > width=8)" > > > > > > > > ****** QUERY 2 ********* > > > > select > > com_oferta.cd_oferta > > from > > com_oferta > > left join com_trafego on com_trafego.cd_oferta = com_oferta.cd_oferta > > left join vw_loc_origem_destino2 on vw_loc_origem_destino2.cd_codigo = > 99 > > where > > com_oferta.nr_oferta = 42 > > > > Analyze da QUERY 2: > > > > "Nested Loop Left Join (cost=11.73..13.51 rows=4 width=4)" > > " -> Hash Left Join (cost=2.10..3.77 rows=2 width=4)" > > " Hash Cond: (com_oferta.cd_oferta = com_trafego.cd_oferta)" > > " -> Seq Scan on com_oferta (cost=0.00..1.63 rows=2 width=4)" > > " Filter: (nr_oferta = 42)" > > " -> Hash (cost=1.49..1.49 rows=49 width=4)" > > " -> Seq Scan on com_trafego (cost=0.00..1.49 rows=49 > > width=4)" > > " -> Materialize (cost=9.63..9.69 rows=2 width=0)" > > " -> Subquery Scan on vw_loc_origem_destino2 (cost=9.63..9.68 > > rows=2 width=0)" > > " -> Unique (cost=9.63..9.66 rows=2 width=124)" > > " -> Sort (cost=9.63..9.63 rows=2 width=124)" > > " Sort Key: loc_cidade.cd_cidade, > > ((loc_cidade.nm_cidade)::text), loc_cidade.cd_pais, loc_cidade.cd_regiao, > > (3)" > > " -> Append (cost=0.00..9.62 rows=2 > width=124)" > > " -> Index Scan using pk_cidade on > > loc_cidade (cost=0.00..8.56 rows=1 width=22)" > > " Index Cond: (cd_cidade = 99)" > > " -> Seq Scan on loc_porto > > (cost=0.00..1.04 rows=1 width=226)" > > " Filter: (cd_porto = 99)" > > > > > Cara, tem como mandar com EXPLAIN ANALYZE? É bem mais fácil de identificar > problemas com o coletor de estatísticas. > > Mais uma coisa, use o explain.depesz.com [1] para facilitar nossa vida, > =D. > > [1] http://explain.depesz.com/ > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130117/71f94692/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Thu, 17 Jan 2013 10:37:42 -0200 > From: Fabio Ebner <[email protected]> > Subject: [pgbr-geral] Problemas com Data. > To: [email protected] > Message-ID: > <CAFxMZbaRShzf010NV1bPYeaU= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Amigos, > > Apareceu um problema aqui pra mim. eu tenho uma tabela no qual o tipo do > campo Dt_documento e DATE, mas olhando o banco apareceu algumas datas > como: "2010181-04-09" / "2010160-11-19" / "2010107-11-29" / "2010106-07-06" > / "20111-03-01" / "20104-05-18" pelo que eu entendi pode existir qualquer > um desses anos correto? por isso ele deixa inserir no banco.. > > esta correto essa minha observacao?? > > Obrigado > > -- > > Fabio Ebner > > *Email: *[email protected] > *Telefone: 13 3221-3616 / 13 3221-6591* > *Endereço: Avenida Ana Costa, 59 Cj 89 - Santos/SP* > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130117/9aac7e2d/attachment-0001.htm > > ------------------------------ > > Message: 5 > Date: Thu, 17 Jan 2013 10:56:41 -0200 > From: Fábio Telles Rodriguez <[email protected]> > Subject: Re: [pgbr-geral] Problemas com Data. > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > <CAAY+2jZ08DFRRTjYN3_sGSMgSi7KwdY075KEEJV= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Em 17 de janeiro de 2013 10:37, Fabio Ebner > <[email protected]>escreveu: > > > Amigos, > > > > Apareceu um problema aqui pra mim. eu tenho uma tabela no qual o tipo do > > campo Dt_documento e DATE, mas olhando o banco apareceu algumas datas > > como: "2010181-04-09" / "2010160-11-19" / "2010107-11-29" / > "2010106-07-06" > > / "20111-03-01" / "20104-05-18" pelo que eu entendi pode existir > qualquer > > um desses anos correto? por isso ele deixa inserir no banco.. > > > > esta correto essa minha observacao?? > > > > > De acordo com a documentação em: > http://www.postgresql.org/docs/current/static/datatype-datetime.html > > O limite superior para data é 294276 DC > > []s > -- > Atenciosamente, > Fábio Telles Rodriguez > blog: http:// <http://www.midstorm.org/~telles/>s< > http://tellesr.wordpress.com/> > avepoint.blog.br > e-mail / gtalk / MSN: [email protected] > Skype: fabio_telles > > Timbira - A empresa brasileira de Postgres > http://www.timbira.com.br > -------------- Pr?a Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20130117/618470a5/attachment.htm > > ------------------------------ > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > Fim da Digest pgbr-geral, volume 49, assunto 20 > *********************************************** >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
