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
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
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 vossiste...@ibest.com.br:
vamos por partes:
-Esta consulta foi feita a analize no pgadimIII
-Mas no aplicativo esta consulta é
2015-04-20 17:53 GMT-03:00 Vilson vossiste...@ibest.com.br:
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
PostgreSQL Brasileira
Subject: Re: [pgbr-geral] consulta lenta
2015-04-20 17:08 GMT-03:00 Vilson vossiste...@ibest.com.br:
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
2015-04-20 17:08 GMT-03:00 Vilson vossiste...@ibest.com.br:
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
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
Em 20 de abril de 2015 10:55, Vilson vossiste...@ibest.com.br 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
-geral] consulta lenta
Em 20 de abril de 2015 10:55, Vilson vossiste...@ibest.com.br escreveu:
Estou usando: Postgresql 9.4
Windows 7 professional
Computador desktop i3 com 4GB de memórioa e HD 500 GB
vb2010
Estava
2015-03-13 14:02 GMT-03:00 Junior Miranda flmirandajun...@gmail.com:
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
Em 13 de março de 2015 15:03, Rafael Fialho rafafial...@gmail.com
escreveu:
Em 13 de março de 2015 12:07, Junior Miranda flmirandajun...@gmail.com
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
To: 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
No dia 13 de março de 2015 às 14:23, Marcelo Silva marc...@ig.com.br
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
Em 13 de março de 2015 12:07, Junior Miranda flmirandajun...@gmail.com
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,
2015-03-13 12:07 GMT-03:00 Junior Miranda flmirandajun...@gmail.com:
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
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
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
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 flmirandajun...@gmail.com*
*Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020
Em 13 de março
É 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:
2015-03-13 13:00 GMT-03:00 Junior Miranda flmirandajun...@gmail.com:
É 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
2015-03-13 13:26 GMT-03:00 Junior Miranda flmirandajun...@gmail.com:
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
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
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 flmirandajun...@gmail.com
escreveu:
O usuário visualiza todos num grid e a partir dai realiza os filtros que
desejar.
Júnior Miranda
*Analista de
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
Em 13 de março de 2015 13:47, Junior Miranda flmirandajun...@gmail.com
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?
2015-03-13 13:32 GMT-03:00 Junior Miranda flmirandajun...@gmail.com:
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
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 flmirandajun...@gmail.com*
*Tel.: *(75) 9191-1678/ 34143042/
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?
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
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
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 ren...@poleti.com.br:
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
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 l...@dutras.org
escreveu:
Renato, por favor siga
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
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
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
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
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 registro de 10
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 procura do
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 seguinte
Em 18-02-2014 16:59, Rafael Fialho Corrêa escreveu:
Em 18 de fevereiro de 2014 16:49, Prof. Cleverson
prof_clever...@uniguacu.edu.br
mailto:prof_clever...@uniguacu.edu.br escreveu:
Em 18-02-2014 16:38, Prof. Cleverson escreveu:
Tenho a seguinte consulta que retorna apenas 1
Em 18-02-2014 17:09, Rafael Fialho Corrêa escreveu:
Em 18 de fevereiro de 2014 16:59, Rafael Fialho Corrêa
r.fia...@ibest.com.br mailto:r.fia...@ibest.com.br escreveu:
Em 18 de fevereiro de 2014 16:49, Prof. Cleverson
prof_clever...@uniguacu.edu.br
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
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 prof_clever...@uniguacu.edu.br
escreveu:
Em 18-02-2014 16:49, Prof. Cleverson
2014-02-18 21:10 GMT-03:00 Renato Poleti ren...@poleti.com.br:
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!:
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 l...@dutras.org
escreveu:
2014-02-18
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
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
Olá!
Será que é possível otimizar a seguinte consulta, executada de hora em hora no
banco:
select count(*) from history;
Essa consulta costuma ter uma duração que varia de 32000.000 ms a 62262.751 ms
conforme o horário em que é executada.
A tabela history possui em média 87
Serve um SELECT pg_relation_size('history') / tamanho do registro ?
Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
moni...@stf.jus.brescreveu:
Olá!
Será que é possível otimizar a seguinte consulta, executada de hora em hora
no banco:
select count(*) from history;
Essa
Olá,
Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
moni...@stf.jus.brescreveu:
Olá!
Será que é possível otimizar a seguinte consulta, executada de hora em hora
no banco:
select count(*) from history;
Essa consulta costuma ter uma duração que varia de 32000.000 ms a
Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
moni...@stf.jus.br escreveu:
Será que é possível otimizar a seguinte consulta, executada de hora em hora
no banco:
select count(*) from history;
Essa consulta costuma ter uma duração que varia de 32000.000 ms a 62262.751
ms conforme o
Vixe, desculpem pelo último POST. Não havia percebido que o problema
está em uma ferramenta externa... sorry...
--
TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
Oi Monica,
Seguindo nas suas razoáveis premissas:
A tabela history possui em média *87 milhões* de registros.
É uma tabela que sofre muito insert/update/delete.
Faço analyze e reindexação semanalmente.
Tem como fazer com mais frequência, como por exemplo diariamente? Pelo
volume de
Vita Voom Support wrote:
Não tenho certeza quanto ao funcionamentoi específico do JDBC, mas
mesmo se
usar uma API direta como a libpq verá como funciona perfeitamente. Também já
fiz isto em C/libpq e em Python/psycopg2 também e funciona sem problemas.
Complementando, pgExpress é da Vita
Hello all,
Pode fazer com cursor ou sem cursor isso não vai resolver o problema do
colega, espero que tenha acompanhado a thread, Firebird trabalha de
forma diferente, ele não envia todos os registros de uma vez, ele envia
sob demanda, os dados não vem todos para a máquina cliente, você
Fabricio Veiga escreveu:
Certo senhores!
Gostaria primeiramente de agradecer a todos pelas informações
disponibilizadas.
Só gostaria de saber como faço para usar DECLARE e FETCH em uma
consulta simples, como por exemplo,
select * from tabela.
Obrigado, mais uma vez!
Fabrício Veiga
aqui
Steve Howe wrote:
Ainda assim o PostGreSql executaria primeiro o cursor para depois ir
enviando os registros, o que não resolveria para o que ele precisa.
Sim, o PostgreSQL primeiro executaria o cursor, da mesma forma que o
Firebird,
Oracle ou qualquer outro. Assim que obtesse um
Hello all,
Steve Howe wrote:
Existe a opção de seria usar DECLARE [1] /FETCH [2] para retornar os
resultados em conjuntos menores. Há algumas APIs que fazem isso
automaticamente, dependendo é claro da linguagem de acesso utilizada.
Ainda assim o PostGreSql executaria primeiro o
Certo senhores!
Gostaria primeiramente de agradecer a todos pelas informações
disponibilizadas.
Só gostaria de saber como faço para usar DECLARE e FETCH em uma consulta
simples, como por exemplo,
select * from tabela.
Obrigado, mais uma vez!
Fabrício Veiga
2008/11/20 Steve Howe [EMAIL
Boa tarde senhores!
Tenho um servidor Linux, mas precisamente um Suse, com versão do PostgreSQL
8.3.1.
Eu tenho na base de dados, uma tabela com + / - 420 mil registros. Ao
executar a consulta (select * from tabela),
o tempo de execução é em torno de 7 segundos. O servidor é um Celeron 2.66
com 1
Olá,
Pode começar pela atualização do seu PostgreSQL para uma versão mais
nova 8.3.5 e no shared_buffers [1].
[1] http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html
Uma questão. Você realmente precisar fazer um select * from tabela?
Não terá nenhuma condição na
Fabricio Veiga wrote:
Boa tarde senhores!
Tenho um servidor Linux, mas precisamente um Suse, com versão do
PostgreSQL 8.3.1. http://8.3.1.
Eu tenho na base de dados, uma tabela com + / - 420 mil registros. Ao
executar a consulta (select * from tabela),
o tempo de execução é em torno de
Hello all,
Fabricio Veiga wrote:
Boa tarde senhores!
Tenho um servidor Linux, mas precisamente um Suse, com versão do
PostgreSQL 8.3.1. http://8.3.1.
Eu tenho na base de dados, uma tabela com + / - 420 mil registros. Ao
executar a consulta (select * from tabela),
o tempo de execução
Steve Howe wrote:
Existe a opção de seria usar DECLARE [1] /FETCH [2] para retornar os
resultados em conjuntos menores. Há algumas APIs que fazem isso
automaticamente, dependendo é claro da linguagem de acesso utilizada.
Ainda assim o PostGreSql executaria primeiro o cursor para
4:43 PM
Subject: [pgbr-geral] consulta lenta, ajuda interpretar explain
Galera,
Pode estar na cara mas não estou conseguindo interpretar o explain e a
consulta está muito lenta. Vejam:
SELECT receber.codpedido, max(receber.rec_parcela) AS max_rec_parcela
FROM receber
JOIN pedido
O uso de OR é sempre uma coisa complicada.
Ao invés disso, porque não utilizas IN
WHERE pedido.status in (4,44,59)
depois, verifique se pedido.status tem algum índice. Pode estar aí seu
problema.
2008/8/19 José Carlos Messias [EMAIL PROTECTED]
Galera,
Pode estar na cara mas não estou
Quando montei a view utilizei o IN e o postgresql converteu para OR,
acredito que seja o ANALIZADOR de consultas dele que prefere assim.
Estou fazendo testes para ver se melhora o performance, o que estou
conseguindo visualizar é que quando acessa as tabelas diretamente,
roda que uma beleza, mas
CREATE INDEX idx_pedido_status ON pedido USING btree (status)
2008/8/19 Rudinei Dias [EMAIL PROTECTED]:
O uso de OR é sempre uma coisa complicada.
Ao invés disso, porque não utilizas IN
WHERE pedido.status in (4,44,59)
depois, verifique se pedido.status tem algum índice. Pode estar aí
68 matches
Mail list logo
