Re: [pgbr-geral] Consulta a código NCM

2016-04-20 10:03 GMT-03:00 Michel Luiz Milezzi : > > Luciano, sugiro você dar uma olhada nessa extensão: > > http://www.postgresql.org/docs/current/static/ltree.html > > Ela fornece exatamente o que você precisa. > > Abraço! > > Estava escrevendo quando seu e-mail chegou. :) Acho que isto resolve m

Re: [pgbr-geral] Consulta a código NCM

> > Pessoal, > > Gostaria de compartilhar um problema e verificar se alguém pode me dar uma > opinião. > > Tenho a necessidade de associar características a um NCM > . > Um código NC

[pgbr-geral] Consulta a código NCM

Pessoal, Gostaria de compartilhar um problema e verificar se alguém pode me dar uma opinião. Tenho a necessidade de associar características a um NCM . Um código NCM é formado da s

Re: [pgbr-geral] Consulta Cross-Tab

Em 19 de fevereiro de 2016 09:14, André Ormenese escreveu: > > > > >> 2016-02-18 17:32 GMT-02:00 André Ormenese : >> >>> Boa tarde pessoal. >>> >>> Vou dar um exemplo de consulta em cross-tab que gostaria de fazer, e >>> vejam se é possível. >>> >>> Tenho duas tabelas, uma com código e descrição

Re: [pgbr-geral] Consulta Cross-Tab

Em 19 de fevereiro de 2016 09:45, Osvaldo Kussama escreveu: > Em 18/02/16, André Ormenese escreveu: > > Boa tarde pessoal. > > > > Vou dar um exemplo de consulta em cross-tab que gostaria de fazer, e > vejam > > se é possível. > > > > Tenho duas tabelas, uma com código e descrição de produtos do

Re: [pgbr-geral] Consulta Cross-Tab

Em 18/02/16, André Ormenese escreveu: > Boa tarde pessoal. > > Vou dar um exemplo de consulta em cross-tab que gostaria de fazer, e vejam > se é possível. > > Tenho duas tabelas, uma com código e descrição de produtos do sangue, e > outra que armazena os dados de resultados de bolsas de sangue frac

Re: [pgbr-geral] Consulta Cross-Tab

> 2016-02-18 17:32 GMT-02:00 André Ormenese : > >> Boa tarde pessoal. >> >> Vou dar um exemplo de consulta em cross-tab que gostaria de fazer, e >> vejam se é possível. >> >> Tenho duas tabelas, uma com código e descrição de produtos do sangue, e >> outra que armazena os dados de resultados de bols

Re: [pgbr-geral] Consulta Cross-Tab

André, Faltou especificar a ordenação no segundo parâmetro do crosstab e especificar descrição no lugar do produto: Select * from crosstab ( $$select bolsa,*descricao*,qtdade from fraciona inner join tproduto on tproduto.co

[pgbr-geral] Consulta Cross-Tab

Boa tarde pessoal. Vou dar um exemplo de consulta em cross-tab que gostaria de fazer, e vejam se é possível. Tenho duas tabelas, uma com código e descrição de produtos do sangue, e outra que armazena os dados de resultados de bolsas de sangue fracionada. Uma bolsa fracionada pode gerar um ou mai

[pgbr-geral] Consulta usando ntile

Pessoal, Tenho uma tabela com umas 40 colunas de indicadores, onde a maioria das colunas permite valores nulos. Preciso de uma view que classifique cada indicador em 3 quartis, desconsiderando os valores nulos. Atualmente estou usando o sql abaixo para montar a view. Está funcionando corretamente.

Re: [pgbr-geral] Consulta que não está usando índices - alguma dica? EXPLAIN incluso

Tirei a restrição do índice e funcionou... Valeu! Em 18 de setembro de 2015 14:41, Eduardo Bohrer escreveu: > Eis o índice: >> "idx_movim_website" UNIQUE, btree (ecommerce_orderid_fk) WHERE >> ecommerce_orderid_fk IS NOT NULL >> > > Posso estar falando bobagem. > > Mas acho que o fato de seu

Re: [pgbr-geral] Consulta que não está usando índices - alguma dica? EXPLAIN incluso

> > Eis o índice: > "idx_movim_website" UNIQUE, btree (ecommerce_orderid_fk) WHERE > ecommerce_orderid_fk IS NOT NULL > Posso estar falando bobagem. Mas acho que o fato de seu índice ser condicional (WHERE ecommerce_orderid_fk IS NOT NULL) está invalidando ele para esta query pois a restrição

[pgbr-geral] Consulta que não está usando índices - alguma dica? EXPLAIN incluso

A tabela "movimento" (com todos os pedidos) tem um milhão de registros. Destes, umas poucas dezenas têm "ecommerce_orderid_fk" não-nulo: SELECT count(*) FROM movimento WHERE ecommerce_orderid_fk is not null; count --- 35 (1 row) Eis o índice: "idx_movim_website" UNIQUE, btree (ecomm

Re: [pgbr-geral] Consulta utilizando LIKE em campo varchar

Remova os índices com pouca utilização. Farei isso, porém estou tentando entender porque alguns índices não estão sendo utilizados antes de removê-los. Não é a única. Se você criar um índice GIN, você pode usar a mesma consulta acima que ele irá usar o índice. Uma vantagem do índice GIN em relação

Re: [pgbr-geral] Consulta utilizando LIKE em campo varchar

On 07-08-2015 16:19, Fernando Cambiaghi wrote: SELECT idx_scan, indexrelname FROM pg_stat_user_indexes WHERE relname = 'cliente'; 215072; "pk_cliente" 14; "idx_cliente_inclusao" 14; "idx_filial_data_atualizacao" 9; "idx_nr_cpf_cgc" 0; "idx_rg" 0; "id

[pgbr-geral] Consulta utilizando LIKE em campo varchar

Boa tarde. Tenho uma tabela com 2.824.756 registros. É uma tabela com dados cadastrais de pessoas físicas e jurídicas. Realizei uma consulta na estatística de utilização dos índices SELECT idx_scan, indexrelname FROM pg_stat_user_indexes WHERE relname = 'cliente'; 215072; "pk_cliente" 14;

Re: [pgbr-geral] Consulta complicada

Em 27/07/15, Stclara escreveu: > Salve, galera. > Gostaria de saber se alguém já recebeu um pedido destes e como conseguiu > resolver: > - Uma tabela com os campos nome e cores; > - Ex: > nome cores > carlos azul, vermelho, amarelo > josé

Re: [pgbr-geral] Consulta complicada

2015-07-28 13:17 GMT-03:00 Tarcisio Martins : > Legal a solução mas se existir muitas cores vai ser necessário escrever um > gerador desse script, senão fica inviável. Além disso, para criar este > gerador é necessário capturar todas as cores possíveis, o que agrega mais > complexidade para este c

Re: [pgbr-geral] Consulta complicada

Legal a solução mas se existir muitas cores vai ser necessário escrever um gerador desse script, senão fica inviável. Além disso, para criar este gerador é necessário capturar todas as cores possíveis, o que agrega mais complexidade para este cenário da solução. Em 28 de julho de 2015 13:09, Mathe

Re: [pgbr-geral] Consulta complicada

2015-07-27 20:25 GMT-03:00 Stclara : > Gostaria de saber se alguém já recebeu um pedido destes e como conseguiu > resolver: > - Uma tabela com os campos nome e cores; > - Ex: > nome cores > carlos azul, vermelho, amarelo > josé

Re: [pgbr-geral] Consulta complicada

Cara, acho que compensa você refatorar o modelo. Transforme esta coluna cores em uma tabela e crie outra tabela intermediária para definir um relacionamento "Muitos para Muitos". Desta forma seu modelo fica normalizado, o que deve ser coerente em qualquer modelo. Do jeito que está, ocorre a quebra

[pgbr-geral] Consulta complicada

Salve, galera. Gostaria de saber se alguém já recebeu um pedido destes e como conseguiu resolver: - Uma tabela com os campos nome e cores; - Ex: nome cores carlos azul, vermelho, amarelo josé branco, cinza, azu

Re: [pgbr-geral] Consulta pelo campo primário não funciona

Le 15 juin 2015 11:58:32 GMT-03:00, Marcos - GMail a écrit : >RESOLVIDO! Legal, mas a linha de assunto não é a primeira linha do corpo, é aquela que normalmente aparece entre os destinatários e o corpo da mensagem. Neste caso, ficaria algo como ‘RESOLVIDO: Consulta pelo campo primário não fun

Re: [pgbr-geral] Consulta pelo campo primário não funciona

RESOLVIDO! Leandro, é exatamente que venho a algum tempo fazendo! Estou trocando em nossos clientes, o servidores windows por linux, onde uso Ubuntu Server LTS - Sempre o mais estável! Marcos André G.A Trabin Softwarre & Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *tw

Re: [pgbr-geral] Consulta pelo campo primário não funciona

Le 13 juin 2015 09:15:23 GMT-03:00, Marcos - GMail a écrit : > >Foi isto mesmo, rodei um reindex e funcionou. O que esta acontecendo em >meu >servidor, é que estou sendo assolado por vírus. Sempre má ideia ter dados numa plataforma vulnerável a vírus. >*Como eu mudo o status da lista para res

Re: [pgbr-geral] Consulta pelo campo primário não funciona

Matheus, tu acertou em cheio, sendo que acabei descobrindo antes de ler, mas a tua resposta foi a certa. Mesmo sem toda a informação que os demais participantes desta lista pediram, tu conseguiu dar o tiro correto. Foi isto mesmo, rodei um reindex e funcionou. O que esta acontecendo em meu servido

Re: [pgbr-geral] Consulta pelo campo primário não funciona

Le 12 juin 2015 14:36:54 GMT-03:00, Marcos - GMail a écrit : >Pessoal, é a primeira vez que estou colocando algo na lista. Hoje venho >pedir socorro. Então, vamos aprender a pedir socorro? >Tenho uma tabela assim: >CREATE TABLE "Produto" >( > "CodigoInternoProduto" integer NOT NULL DEFAULT >n

Re: [pgbr-geral] Consulta pelo campo primário não funciona

2015-06-12 14:36 GMT-03:00 Marcos - GMail : > O detalhe é, que ao fazer um simples select pelo campo primário, o banco > não retorna o produto, e se fizer por qualquer outro, dá certo. > > Pelo que você descreveu, aparentemente o problema está em índice corrompido. Tente desabilitar o indexscan [1

Re: [pgbr-geral] Consulta pelo campo primário não funciona

> > Tenho uma tabela assim: > CREATE TABLE "Produto" > ( > "CodigoInternoProduto" integer NOT NULL DEFAULT > nextval('"Produto_CodigoInternoProduto_seq"'::regclass), > "CodigoEmpresaProduto" integer DEFAULT 0, > "CodigoProduto" character varying(20), > "DescricaoProduto" character varying(5

[pgbr-geral] Consulta pelo campo primário não funciona

Pessoal, é a primeira vez que estou colocando algo na lista. Hoje venho pedir socorro. Tenho uma tabela assim: CREATE TABLE "Produto" ( "CodigoInternoProduto" integer NOT NULL DEFAULT nextval('"Produto_CodigoInternoProduto_seq"'::regclass), "CodigoEmpresaProduto" integer DEFAULT 0, "CodigoPr

Re: [pgbr-geral] consulta lenta resolvido

funcionou normal. Agora vou ter que achar uma solução para estas pesquisas, são simples mas tenho que botar na mesma linha. Obrigado pela ajuda. From: Vilson Sent: Wednesday, April 22, 2015 8:11 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] consulta lenta Mudei o programa

Re: [pgbr-geral] consulta lenta

banco de dados, nem o computador e como é a segunda vez que acontece fico em dúvida. From: Vilson Sent: Monday, April 20, 2015 6:20 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] consulta lenta - Não medi porque achei a aplicação pequena; - Esta é uma aplicação desktop - O

Re: [pgbr-geral] consulta lenta

Oliveira Sent: Monday, April 20, 2015 6:03 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] consulta lenta 2015-04-20 17:53 GMT-03:00 Vilson : vamos por partes: -Esta consulta foi feita a analize no pgadimIII -Mas no aplicativo esta consulta é muito lenta quando não

Re: [pgbr-geral] consulta lenta

2015-04-20 17:53 GMT-03:00 Vilson : > vamos por partes: > > -Esta consulta foi feita a analize no pgadimIII > -Mas no aplicativo esta consulta é muito lenta quando não trava o > aplicativo, sendo que tem somente 1500 registros. > -Estava funcionando normalmente sem problemas no aplicat

Re: [pgbr-geral] consulta lenta

PostgreSQL Brasileira Subject: Re: [pgbr-geral] consulta lenta 2015-04-20 17:08 GMT-03:00 Vilson : EXPLAIN ANALYZE SELECT * FROM TABCFR ORDER BY CFR_SERIE,CFR_NUMERO DESC "Sort (cost=458.82..462.49 rows=1467 width=1621) (actual time=18.057..18.112 rows=1467 loops=1)" " Sort

Re: [pgbr-geral] consulta lenta

2015-04-20 17:08 GMT-03:00 Vilson : > > EXPLAIN ANALYZE SELECT * FROM TABCFR ORDER BY CFR_SERIE,CFR_NUMERO DESC > > > > "Sort (cost=458.82..462.49 rows=1467 width=1621) (actual > time=18.057..18.112 rows=1467 loops=1)" > > " Sort Key: cfr_serie, cfr_numero" > > " Sort Method: quicksort Memory: 297

Re: [pgbr-geral] consulta lenta

20, 2015 11:06 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] consulta lenta Em 20 de abril de 2015 10:55, Vilson escreveu: Estou usando: Postgresql 9.4 Windows 7 professional Computador desktop i3 com 4GB de memórioa e H

Re: [pgbr-geral] consulta lenta

Em 20 de abril de 2015 10:55, Vilson escreveu: > Estou usando: Postgresql 9.4 > Windows 7 professional > Computador desktop i3 com 4GB de memórioa e HD 500 > GB > vb2010 > > Estava funcionando ok até que do nada ficou lento

[pgbr-geral] consulta lenta

Estou usando: Postgresql 9.4 Windows 7 professional Computador desktop i3 com 4GB de memórioa e HD 500 GB vb2010 Estava funcionando ok até que do nada ficou lento demais, chegando ao ponto da aplicação parar. Faço uma seleção

Re: [pgbr-geral] Consulta muito lenta

É difícil sem ter idéia do que é mais restritivo, mas tenta esse índice em vehiclebusserviceplanned trip_program_id, begintimestamp, COALESCE(endtimestamp, 'infinity'), vehiclebusserviceplannedid Não esquecer de depois de criar o índice fazer um analyze ___

Re: [pgbr-geral] Consulta muito lenta

Matheus, Segui as suas sugestões, criei o indice *(trip_program_id, begintimestamp, COALESCE(endtimestamp, 'infinity')**)* que não surtiu muito efeito e em seguida mudei a consulta conforme você sugeriu, neste eu tive um resultado considerável, baixou para 28845.757 ms. SELECT '' as linha, '00:0

Re: [pgbr-geral] Consulta muito lenta

2015-04-06 16:58 GMT-03:00 Matheus de Oliveira : > On Mon, Apr 6, 2015 at 4:46 PM, Ariel Alves > wrote: > >> -> Index Scan using >> vehiclebusserviceplanned_tripprogramid_idx on vehiclebusserviceplanned vbp1 >> (cost=0.00..117.25 rows=9 width=16) (actual time=0.387..0.476 rows=

Re: [pgbr-geral] Consulta muito lenta

On Mon, Apr 6, 2015 at 4:46 PM, Ariel Alves wrote: > -> Index Scan using > vehiclebusserviceplanned_tripprogramid_idx on vehiclebusserviceplanned vbp1 > (cost=0.00..117.25 rows=9 width=16) (actual time=0.387..0.476 rows=0 > loops=736406) >Index Cond: (tr

[pgbr-geral] Consulta muito lenta

Boa tarde, Pessoal já esgotou aqui pelo meu lado, foi precisar da experiência de vocês, minha aplicação faz uma consulta muito muito lenta que já está gerando demandas de suporte. Já criei e removi indices, fiz vacuum full, reindex e analyse e não surtiu efeito. Está batendo um Total runtime: 353

Re: [pgbr-geral] Consulta lenta

Em 13 de março de 2015 15:03, Rafael Fialho escreveu: > Em 13 de março de 2015 12:07, Junior Miranda > escreveu: > >> Boa tarde a todos >> >> Estou com problemas de lentidão em uma consulta select * from. A tabelas >> possui 20 mil registros, e estou tentando criar um cursor. O problema é que >>

Re: [pgbr-geral] Consulta lenta

Em 13 de março de 2015 12:07, Junior Miranda escreveu: > Boa tarde a todos > > Estou com problemas de lentidão em uma consulta select * from. A tabelas > possui 20 mil registros, e estou tentando criar um cursor. O problema é que > não estou conseguindo > retornar os dados, fica informando que a

Re: [pgbr-geral] Consulta lenta

No dia 13 de março de 2015 às 14:23, Marcelo Silva escreveu: > Olha, vou te atazanar neste assunto [image: Alegre] > Essa cultura que vem de aplicações Desktop, lá dos primordios dos DBFs > onde se usavam TTables, cultura muito usada no Clipper também. > Entendo que é muito bom você trabalhar c

Re: [pgbr-geral] Consulta lenta

: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Consulta lenta Tentei fazer isso, é uma mudança de cultura e não foi bem recebida... outros bancos, como firebird, essa lentidão não é tão acentuada... Alguma sugestão dentro deste cenário?? Júnior Miranda Analista de Sistemas

Re: [pgbr-geral] Consulta lenta

2015-03-13 14:02 GMT-03:00 Junior Miranda : > Obrigado pela atenção Matheus, nesse caso a função que propus estaria > correta bastando apenas um open pela aplicação?? Não, a função não estaria correta. Ela não deveria navegar no cursor, ela deveria abrí-lo e retornar o refcursor para que a aplic

Re: [pgbr-geral] Consulta lenta

Obrigado pela atenção Matheus, nesse caso a função que propus estaria correta bastando apenas um open pela aplicação?? Júnior Miranda *Analista de Sistemas* *Especializando em Sistemas Computacionais* *E-mail: flmirandajun...@gmail.com * *Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020 Em 13

Re: [pgbr-geral] Consulta lenta

2015-03-13 13:32 GMT-03:00 Junior Miranda : > Tenho uma consulta de produtos que possue, no momento, 20 mil registros. > Infelizmente para esta consulta eu precisaria retornar todos para que a > partir dai o usuário pudesse realizar os seus filtros. Com essa quantidade > de registros apresenta uma

Re: [pgbr-geral] Consulta lenta

Em 13 de março de 2015 13:47, Junior Miranda escreveu: > Tentei fazer isso, é uma mudança de cultura e não foi bem recebida... > outros bancos, como firebird, essa lentidão não é tão acentuada... Alguma > sugestão dentro deste cenário?? > > Já pensou em fazer paginação? Mostrar de 100 em 100 regi

Re: [pgbr-geral] Consulta lenta

Tentei fazer isso, é uma mudança de cultura e não foi bem recebida... outros bancos, como firebird, essa lentidão não é tão acentuada... Alguma sugestão dentro deste cenário?? Júnior Miranda *Analista de Sistemas* *Especializando em Sistemas Computacionais* *E-mail: flmirandajun...@gmail.com * *Te

Re: [pgbr-geral] Consulta lenta

Porque não força o usuário a fazer o filtro antes? Abra a tabela depois que tiver o filtro. Em 13 de março de 2015 13:34, Junior Miranda escreveu: > O usuário visualiza todos num grid e a partir dai realiza os filtros que > desejar. > > Júnior Miranda > *Analista de Sistemas* > *Especializando e

Re: [pgbr-geral] Consulta lenta

O usuário visualiza todos num grid e a partir dai realiza os filtros que desejar. Júnior Miranda *Analista de Sistemas* *Especializando em Sistemas Computacionais* *E-mail: flmirandajun...@gmail.com * *Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020 Em 13 de março de 2015 13:32, Junior Miran

Re: [pgbr-geral] Consulta lenta

Tenho uma consulta de produtos que possue, no momento, 20 mil registros. Infelizmente para esta consulta eu precisaria retornar todos para que a partir dai o usuário pudesse realizar os seus filtros. Com essa quantidade de registros apresenta uma lentidão na abertura da pesquisa. Não fetch X em X p

Re: [pgbr-geral] Consulta lenta

2015-03-13 13:26 GMT-03:00 Junior Miranda : > A questão é que inicialmente precisarei retornar todos os registro, e como > a tendência é que eles aumentem um pouco, precisaria fazer FETCH de X em X > para diminuir o gargalo na abertura. A tendência é que com o aumento essa > lentidão aumente...

Re: [pgbr-geral] Consulta lenta

A questão é que inicialmente precisarei retornar todos os registro, e como a tendência é que eles aumentem um pouco, precisaria fazer FETCH de X em X para diminuir o gargalo na abertura. A tendência é que com o aumento essa lentidão aumente... Júnior Miranda *Analista de Sistemas* *Especializando

Re: [pgbr-geral] Consulta lenta

2015-03-13 13:00 GMT-03:00 Junior Miranda : > É necessário, sim, infelizmente!! Possuo outras pesquisas com filtros, mas > esta em específico será necessário retornar todos os 20 mil registros. A > saída seria realmente o uso de cursor?? Não vejo nenhum motivo pra usar cursor. Eu usaria uma funç

Re: [pgbr-geral] Consulta lenta

É necessário, sim, infelizmente!! Possuo outras pesquisas com filtros, mas esta em específico será necessário retornar todos os 20 mil registros. A saída seria realmente o uso de cursor?? Júnior Miranda *Analista de Sistemas* *Especializando em Sistemas Computacionais* *E-mail: flmirandajun...@gma

Re: [pgbr-geral] Consulta lenta

2015-03-13 12:07 GMT-03:00 Junior Miranda : > CREATE OR REPLACE FUNCTION fn_busca_Produto() >RETURNS TABLE(oprd_id integer, oprd_nome varchar(50)) As > $BODY$ > DECLARE >ref refcursor; >cur_produtos cursor for select prd_id, prd_nome from produto; > begin > OPEN cur_produtos; > LOOP

[pgbr-geral] Consulta lenta

Boa tarde a todos Estou com problemas de lentidão em uma consulta select * from. A tabelas possui 20 mil registros, e estou tentando criar um cursor. O problema é que não estou conseguindo retornar os dados, fica informando que a query está sendo executada e não sai disso. O objetivo é agilizar o

Re: [pgbr-geral] Consulta não está utilizando índice

2015-03-05 13:10 GMT-03:00 Fernando Cambiaghi : >> >> No mínimo, declare CPF e CNPJ como chaves também. >> > Temos apenas um campo para estes dois, chamado nr_cpf_cgc( varchar(14) ), > sendo que é um índice único com validação para CPF e CNPJ na inclusão. Exatamente o que sugeri, parabéns. Assim

Re: [pgbr-geral] Consulta não está utilizando índice

> > Para sua consulta, o índice ideal seria: > > CREATE INDEX ON cliente (cd_filial_inclusao, cd_cliente); > > Assim é possível buscar rapidamente o "cd_filial_inclusao" pelo número > exato e então só pegar o último elemento, com maior "cd_cliente". > > Matheus, apresento o retorno da sua dica:

Re: [pgbr-geral] Consulta não está utilizando índice

> > Possivelmente não é viável ou interessante mudar tudo, mas a chave > primária poderia, em tese, ser definida sobre um atributo ‘CPF/CNPJ’, > com restrições de integridade tanto para validar CPF ou CNPJ quanto > para, na dificuldade de normalizar, garantir que outros atributos > estão consistent

Re: [pgbr-geral] Consulta não está utilizando índice

> > Para sua consulta, o índice ideal seria: > > CREATE INDEX ON cliente (cd_filial_inclusao, cd_cliente); > > Assim é possível buscar rapidamente o "cd_filial_inclusao" pelo número > exato e então só pegar o último elemento, com maior "cd_cliente". > > Interessante. Vou fazer uns testes aqui,

Re: [pgbr-geral] Consulta não está utilizando índice

2015-03-05 12:55 GMT-03:00 Fernando Cambiaghi : >> cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? > > Sim, cd_cliente é a chave primária. Essa é uma tabela que foi criada em > nosso sistema em 1998 e não está normalizada como deveria, mas acho que nem > vem ao caso. Essa tabel

Re: [pgbr-geral] Consulta não está utilizando índice

> > cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? Sim, cd_cliente é a chave primária. Essa é uma tabela que foi criada em nosso sistema em 1998 e não está normalizada como deveria, mas acho que nem vem ao caso. Essa tabela armazena clientes PF e PJ, por isso a PK não é o CP

Re: [pgbr-geral] Consulta não está utilizando índice

2015-03-05 10:28 GMT-03:00 Fernando Cambiaghi : > Ao executar a seguinte consulta : > > SELECT max( cd_cliente ) FROM cliente WHERE cd_filial_inclusao = 563 > > O resultado do plano de acesso é o seguinte: > > ___

Re: [pgbr-geral] Consulta não está utilizando índice

On 05-03-2015 10:28, Fernando Cambiaghi wrote: > Neste caso a consulta não deveria utilizar o índice acima para realizar a > busca? Pois até onde tenho conhecimento, ainda que um índice seja composto, > se eu utilizar as colunas na ordem do índice na cláusula where, ainda que > não utilize todas as

[pgbr-geral] Consulta não está utilizando índice

Bom dia. Estou com um problema e não sei o que está causando este. Ao executar a seguinte consulta : SELECT max( cd_cliente ) FROM cliente WHERE cd_filial_inclusao = 563 O resultado do plano de acesso é o seguinte: ___

Re: [pgbr-geral] Consulta em conteúdo XML

Deve precisar de XSLT, aqui achei uma referência: http://translate.google.com/translate?hl=nl&rurl=translate.google.nl&sl=nl&tl=en&u=http://www.yapf.net/index.php/PostgreSQL_en_xslt Mas.. não tem como guardar os dados em campos não XML e formatar como XML(Json ou outro formato qualquer) depois?

[pgbr-geral] Consulta em conteúdo XML

Pessoal, boa tarde. Versão: PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit Estou me batendo com XML aqui no PostgreSQL e não estou tendo muito sucesso. Queria fazer uma tabela de histórico de execução de alguns relatórios que tenho,

Re: [pgbr-geral] Consulta muito lenta

Em sex, 28 de nov de 2014 19:23, Marcos Thomaz escreveu: > Ariel, na sua consulta existe mesmo essa sequencia de transformações > (cast) concatenando tipos? Porque por exemplo, no trecho: > > (('2014-11-28'::date)::text || ' '::text) || > (tp.departure_time)::text))::timestamp without time zone >

Re: [pgbr-geral] Consulta muito lenta

Ariel, na sua consulta existe mesmo essa sequencia de transformações (cast) concatenando tipos? Porque por exemplo, no trecho: (('2014-11-28'::date)::text || ' '::text) || (tp.departure_time)::text))::timestamp without time zone >= begintimestamp) o custo dessa série de concatenações é maior do q

Re: [pgbr-geral] Consulta muito lenta

On 28-11-2014 16:40, Ariel Alves wrote: > Fabrízio, > > As estatísticas estão atualizadas sim, apesar de ser uma base nova rodei um > analyze em todas conforme você sugeriu. > Após o ANALYZE algo mudou? Ps: evite top-posting. -- Fabrízio de Royes Mello Timbira - http://www.timbir

Re: [pgbr-geral] Consulta muito lenta

Fabrízio, As estatísticas estão atualizadas sim, apesar de ser uma base nova rodei um analyze em todas conforme você sugeriu. Obrigado. Em 28 de novembro de 2014 16:19, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: > On 28-11-2014 16:13, Ariel Alves wrote: > > Boa tarde preza

Re: [pgbr-geral] Consulta muito lenta

On 28-11-2014 16:13, Ariel Alves wrote: > Boa tarde prezados, > > > Venho com mais um pedido de ajuda a vocês, estou homologando uma aplicação > e logo no inicio já me deparei com uma consulta muito lenta, peguei o > resultado explain analyze, vi que a lentidão estava concentrada > exclusivamente

[pgbr-geral] Consulta muito lenta

Boa tarde prezados, Venho com mais um pedido de ajuda a vocês, estou homologando uma aplicação e logo no inicio já me deparei com uma consulta muito lenta, peguei o resultado explain analyze, vi que a lentidão estava concentrada exclusivamente em um "Index Scan Backward". Apesar de está com o res

Re: [pgbr-geral] consulta lenta

Boa noite a todos, Segue os testes, quem puder refazer o testes e postar os resultador seria legal também. Ressalto, que isto é pra mostrar que o fillfactor altera e muito na velocidade dos índices (até pra consulta) (o assunto é consulta lenta) Observem os resultados, vejam que melhorou um pou

Re: [pgbr-geral] consulta lenta

nas proximas eu respondo conforme orientado... nao vou discurtir quem sabe o que, quero ajudar... como jah foi solucionado este caso de lentidao estarei ajudando outras questoes... abs Em 19/02/2014 19:56, "Guimarães Faria Corcete DUTRA, Leandro" escreveu: > Renato, por favor siga as regras da l

Re: [pgbr-geral] consulta lenta

Renato, por favor siga as regras da lista e o exemplo dos colegas: responda após o texto respondido. 2014-02-19 16:39 GMT-03:00 Renato Poleti : > pessoal quando se trata de consulta lenta, pode ser qq questao E? Isso não nos exime de tentar entender a situação antes de dar pitaco. > logo nao

Re: [pgbr-geral] consulta lenta

pessoal quando se trata de consulta lenta, pode ser qq questao, logo nao daria pra responder sem levantar outraa questoes... parabena por ser o dono da verdade... pois entendo mto bem do fillfactor e perguntei pra ele testar... como nao se pronunciou vou mostrar q isto eh quesito de lentidao... Em

Re: [pgbr-geral] consulta lenta

On 19-02-2014 09:04, Renato Poleti wrote: > aproveitando o assunto, o fillfactor é a % que a "folha de pagina" vai ser > utilizada, quanto menor o numero, mais espaco em disco é consumido, pois > cada folha vai ser pouco utilizada... sendo pouco utlizada a duvida é, o > indice é carregado mais rapi

Re: [pgbr-geral] consulta lenta

aproveitando o assunto, o fillfactor é a % que a "folha de pagina" vai ser utilizada, quanto menor o numero, mais espaco em disco é consumido, pois cada folha vai ser pouco utilizada... sendo pouco utlizada a duvida é, o indice é carregado mais rapidamente em memoria e processada mais rapidamente?

Re: [pgbr-geral] consulta lenta

On 18-02-2014 23:17, Renato Poleti wrote: > Deve ter mtos inserts, porem com este recurso podera aumentar o desempenho > dos indices, como sempre , cada caso um caso, tem que testar entre 10 e 100 > ate achar melhor desempenho ir fazendo o explain. Sepuder fazer isto e > postar o resultao de seu ba

Re: [pgbr-geral] consulta lenta

Deve ter mtos inserts, porem com este recurso podera aumentar o desempenho dos indices, como sempre , cada caso um caso, tem que testar entre 10 e 100 ate achar melhor desempenho ir fazendo o explain. Sepuder fazer isto e postar o resultao de seu banco seria bom pra analise. Tente com os seguintes

Re: [pgbr-geral] consulta lenta

On 18-02-2014 21:10, Renato Poleti wrote: > adicione ... > WITH (fillfactor = 10) > Para que? Você estará aumentando o tamanho dos datafiles, o que aumentará a quantidade de I/O para fazer consultas. O fillfactor só é útil em casos específicos (por exemplo, em tabelas com *alta* taxa de atualizaçã

Re: [pgbr-geral] consulta lenta

Concordo que se em disco diferentes, mas tem que administrar pensando em escabilidade e facil manutencao por exemplo, backup so das tables spaces que contem dados uteis, deixando de fora indices Em 19/02/2014 00:27, "Guimarães Faria Corcete DUTRA, Leandro" escreveu: > 2014-02-18 21:10 GMT-03:00 R

Re: [pgbr-geral] consulta lenta

2014-02-18 21:10 GMT-03:00 Renato Poleti : > Para tentar melhorar o desempenho, coloque os indices em tablespace > direfente do tablespace da propria tabela Se estiverem em discos diferentes, se não só complica, sem ganhos. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55

Re: [pgbr-geral] consulta lenta

Para tentar melhorar o desempenho, coloque os indices em tablespace direfente do tablespace da propria tabela e se tiver espaco de sobra adicione ... WITH (fillfactor = 10) Em 18/02/2014 23:08, "Prof. Cleverson" escreveu: > Em 18-02-2014 16:49, Prof. Cleverson escreveu: > >> Em 18-02-2014 16:38,

Re: [pgbr-geral] consulta lenta

Em 18-02-2014 16:49, Prof. Cleverson escreveu: Em 18-02-2014 16:38, Prof. Cleverson escreveu: Tenho a seguinte consulta que retorna apenas 1 registro de 10 colunas: select * from tac_avaliacao left join tac_nota on (codava=avanot) where hisnot=359921 and fasava=81 a tabela avaliação tem 15000

Re: [pgbr-geral] consulta lenta

Em 18-02-2014 17:09, Rafael Fialho Corrêa escreveu: Em 18 de fevereiro de 2014 16:59, Rafael Fialho Corrêa mailto:r.fia...@ibest.com.br>> escreveu: Em 18 de fevereiro de 2014 16:49, Prof. Cleverson mailto:prof_clever...@uniguacu.edu.br>> escreveu: Em 18-02-2014 16:38, Prof. Cle

Re: [pgbr-geral] consulta lenta

Em 18-02-2014 16:59, Rafael Fialho Corrêa escreveu: Em 18 de fevereiro de 2014 16:49, Prof. Cleverson > escreveu: Em 18-02-2014 16:38, Prof. Cleverson escreveu: Tenho a seguinte consulta que retorna apenas 1 registro de 10 colunas:

Re: [pgbr-geral] consulta lenta

Criou um índice para este campo? Marcos André G.A Trabin Softwarre & Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *twitter:* http://twitter.com/lgerardlucas Em 18 de fevereiro de 2014 16:38, Prof. Cleverson < prof_clever...@uniguacu.edu.br> escreveu: > Tenho a seguin

Re: [pgbr-geral] consulta lenta

Em 18 de fevereiro de 2014 16:38, Prof. Cleverson < prof_clever...@uniguacu.edu.br> escreveu: > Index Cond: (fasava = 81)" > " -> Seq Scan on tac_nota (cost=0.00..12469.80 rows=4 width=17) (actual > time=44.727..87.866 rows=2 loops=513)" > Sua consulta faz uma busca sequencial na tabela a pr

Re: [pgbr-geral] consulta lenta

Em 18 de fevereiro de 2014 16:59, Rafael Fialho Corrêa < r.fia...@ibest.com.br> escreveu: > Em 18 de fevereiro de 2014 16:49, Prof. Cleverson < > prof_clever...@uniguacu.edu.br> escreveu: > > Em 18-02-2014 16:38, Prof. Cleverson escreveu: >> >> Tenho a seguinte consulta que retorna apenas 1 regis

Re: [pgbr-geral] consulta lenta

Em 18 de fevereiro de 2014 16:49, Prof. Cleverson < prof_clever...@uniguacu.edu.br> escreveu: > Em 18-02-2014 16:38, Prof. Cleverson escreveu: > > Tenho a seguinte consulta que retorna apenas 1 registro de 10 colunas: >> select * from tac_avaliacao left join tac_nota on (codava=avanot) where >> h

Re: [pgbr-geral] consulta lenta

Em 18-02-2014 16:38, Prof. Cleverson escreveu: Tenho a seguinte consulta que retorna apenas 1 registro de 10 colunas: select * from tac_avaliacao left join tac_nota on (codava=avanot) where hisnot=359921 and fasava=81 a tabela avaliação tem 15000 registros a tabela de notas tem 66 registro

[pgbr-geral] consulta lenta

Tenho a seguinte consulta que retorna apenas 1 registro de 10 colunas: select * from tac_avaliacao left join tac_nota on (codava=avanot) where hisnot=359921 and fasava=81 a tabela avaliação tem 15000 registros a tabela de notas tem 66 registros explain: "Nested Loop (cost=0.00..12474.40 r

  1   2   3   >