Re: [pgbr-geral] consulta lenta resolvido

[Vilson]

O problema foi resolvido. Quando montava a list eu fazia duas novas consultas 
no banco de dados onde eu montava dois novos campos acumulativos, ou seja na 
mesma linha mais de um dado. Não consegui fazer isso na consulta principal. 
Funcionava bem até um certo ponto, quando tirei estas consultas 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 recompilei e instalei novamente no cliente e não deu certo, 
simplesmente parou de funcionar.
Deve ser algo a ver entre o windows – memória – banco de dados.
Sendo que instalei em um computador com as mesmas configurações e funciona 
normalmente.
Não tenho convicção que seja o 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 resultado é trazido de uma só vez;
- Fiz outros testes e realmente ficou lento mas não travou
- Volto a destacar que estava funcionando normalmente em um dia e no outro 
ficou com esta lentidão


From: Matheus de 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 trava o 
aplicativo, sendo que tem somente 1500 registros.
  -Estava funcionando normalmente sem problemas no aplicativo sendo que uso 
o listview no vb2010
  -Instalo em outro computador e funciona normalmente.
  -É o segundo caso que isso ocorre, no primeiro troquei o computador e 
funciona normalmente, com novos registros.
  -Nos dois casos utilizam o windows 7.

Não me parece que seu problema está no banco então. Você chegou a medir todos 
os tempos pela aplicação? Tempo de execução da query no banco, tempo de 
transferência para a aplicação, tempo de renderização, etc.


E de qualquer forma o índice sugerido ainda ajuda. E continuo mantendo as 
práticas ruins vistas anteriormente. É uma aplicação web ou desktop? O 
resultado é trazido todo de uma só vez ou usa-se um cursor? Apenas esta 
consulta está gerando problemas?


Atenciosamente,

-- 

Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres





___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Vilson]

Mudei o programa recompilei e instalei novamente no cliente e não deu certo, 
simplesmente parou de funcionar.
Deve ser algo a ver entre o windows – memória – banco de dados.
Sendo que instalei em um computador com as mesmas configurações e funciona 
normalmente.
Não tenho convicção que seja o 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 resultado é trazido de uma só vez;
- Fiz outros testes e realmente ficou lento mas não travou
- Volto a destacar que estava funcionando normalmente em um dia e no outro 
ficou com esta lentidão


From: Matheus de 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 trava o 
aplicativo, sendo que tem somente 1500 registros.
  -Estava funcionando normalmente sem problemas no aplicativo sendo que uso 
o listview no vb2010
  -Instalo em outro computador e funciona normalmente.
  -É o segundo caso que isso ocorre, no primeiro troquei o computador e 
funciona normalmente, com novos registros.
  -Nos dois casos utilizam o windows 7.

Não me parece que seu problema está no banco então. Você chegou a medir todos 
os tempos pela aplicação? Tempo de execução da query no banco, tempo de 
transferência para a aplicação, tempo de renderização, etc.


E de qualquer forma o índice sugerido ainda ajuda. E continuo mantendo as 
práticas ruins vistas anteriormente. É uma aplicação web ou desktop? O 
resultado é trazido todo de uma só vez ou usa-se um cursor? Apenas esta 
consulta está gerando problemas?


Atenciosamente,

-- 

Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres





___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Vilson]

- Não medi porque achei a aplicação pequena;
- Esta é uma aplicação desktop
- O resultado é trazido de uma só vez;
- Fiz outros testes e realmente ficou lento mas não travou
- Volto a destacar que estava funcionando normalmente em um dia e no outro 
ficou com esta lentidão


From: Matheus de 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 trava o 
aplicativo, sendo que tem somente 1500 registros.
  -Estava funcionando normalmente sem problemas no aplicativo sendo que uso 
o listview no vb2010
  -Instalo em outro computador e funciona normalmente.
  -É o segundo caso que isso ocorre, no primeiro troquei o computador e 
funciona normalmente, com novos registros.
  -Nos dois casos utilizam o windows 7.

Não me parece que seu problema está no banco então. Você chegou a medir todos 
os tempos pela aplicação? Tempo de execução da query no banco, tempo de 
transferência para a aplicação, tempo de renderização, etc.


E de qualquer forma o índice sugerido ainda ajuda. E continuo mantendo as 
práticas ruins vistas anteriormente. É uma aplicação web ou desktop? O 
resultado é trazido todo de uma só vez ou usa-se um cursor? Apenas esta 
consulta está gerando problemas?


Atenciosamente,

-- 

Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres





___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Matheus de Oliveira]

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 aplicativo sendo que
> uso o listview no vb2010
> -Instalo em outro computador e funciona normalmente.
> -É o segundo caso que isso ocorre, no primeiro troquei o computador e
> funciona normalmente, com novos registros.
> -Nos dois casos utilizam o windows 7.
>

Não me parece que seu problema está no banco então. Você chegou a medir
todos os tempos pela aplicação? Tempo de execução da query no banco, tempo
de transferência para a aplicação, tempo de renderização, etc.

E de qualquer forma o índice sugerido ainda ajuda. E continuo mantendo as
práticas ruins vistas anteriormente. É uma aplicação web ou desktop? O
resultado é trazido todo de uma só vez ou usa-se um cursor? Apenas esta
consulta está gerando problemas?

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[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 aplicativo sendo que uso o 
listview no vb2010
-Instalo em outro computador e funciona normalmente.
-É o segundo caso que isso ocorre, no primeiro troquei o computador e 
funciona normalmente, com novos registros.
-Nos dois casos utilizam o windows 7.


From: Matheus de Oliveira 
Sent: Monday, April 20, 2015 5:35 PM
To: Comunidade 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 Key: cfr_serie, cfr_numero"

  " Sort Method: quicksort Memory: 2978kB"

  " -> Seq Scan on tabcfr (cost=0.00..381.67 rows=1467 width=1621) (actual 
time=0.007..0.842 rows=1467 loops=1)"


Essa consulta não parece absurdamente lenta, para estar gerando problemas no 
ambiente como um todo.


De qualquer forma, para essa especificamente você pode criar o seguinte índice:


CREATE INDEX ON tabcfr (cfr_serie, cfr_numero DESC);


De qualquer forma me parece uma péssima consulta, primeiro pelo "SELECT *", 
segundo por cegamente trazer todos os registros. Claro que depende do caso de 
uso.


Atenciosamente,

-- 

Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres





___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Matheus de Oliveira]

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: 2978kB"
>
> " -> Seq Scan on tabcfr (cost=0.00..381.67 rows=1467 width=1621) (actual
> time=0.007..0.842 rows=1467 loops=1)"
>

Essa consulta não parece absurdamente lenta, para estar gerando problemas
no ambiente como um todo.

De qualquer forma, para essa especificamente você pode criar o seguinte
índice:

CREATE INDEX ON tabcfr (cfr_serie, cfr_numero DESC);

De qualquer forma me parece uma péssima consulta, primeiro pelo "SELECT *",
segundo por cegamente trazer todos os registros. Claro que depende do caso
de uso.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Vilson]

Desculpe a demora tive que sair. Não deu certo. veja o explain analyze.

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: 2978kB"

" -> Seq Scan on tabcfr (cost=0.00..381.67 rows=1467 width=1621) (actual 
time=0.007..0.842 rows=1467 loops=1)"

"Planning time: 5.111 ms"

"Execution time: 18.522 ms"


From: Rafael Fialho 
Sent: Monday, April 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 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 com PGAdminIII e também fica demorada mas 
não para.
  Não foi feito nenhuma atualização, e simplesmente fica lenta ou para de 
funcionar. Tem algo a ver com o banco de dados ou o problema é do computador. 
Já fiz o Vacum, reinstalei o banco de dados, reinstalei a aplicação, mas nada 
funciona.

Nenhuma de suas intervenções, ao meu ver, poderia resolver este problema. 
Eexecute um analyze em sua base de dados e tente novamente. Caso não resolva o 
problema, informe o plano de execução de sua query utilizando o explain analyze.



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Rafael Fialho]

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 demais, chegando ao
> ponto da aplicação parar. Faço uma seleção com PGAdminIII e também fica
> demorada mas não para.
> Não foi feito nenhuma atualização, e simplesmente fica lenta ou para de
> funcionar. Tem algo a ver com o banco de dados ou o problema é do
> computador. Já fiz o Vacum, reinstalei o banco de dados, reinstalei a
> aplicação, mas nada funciona.
>

Nenhuma de suas intervenções, ao meu ver, poderia resolver este problema.
Eexecute um analyze em sua base de dados e tente novamente. Caso não
resolva o problema, informe o plano de execução de sua query utilizando o
explain analyze.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] consulta lenta

[Vilson]

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 com PGAdminIII e também fica demorada mas não 
para.
Não foi feito nenhuma atualização, e simplesmente fica lenta ou para de 
funcionar. Tem algo a ver com o banco de dados ou o problema é do computador. 
Já fiz o Vacum, reinstalei o banco de dados, reinstalei a aplicação, mas nada 
funciona. 

Vilson Zin
Vos Software Ltda
vossiste...@ibest.com.br
vossiste...@hotmail.com
(54)3292-2610
(54)9974-0345
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Rafael Fialho]

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
>> não estou conseguindo
>> retornar os dados, fica informando que a query está sendo executada e não
>> sai disso. O objetivo é agilizar o retorno destes registros.
>>
>> ()
>> $BODY$
>>LANGUAGE 'plpgsql' VOLATILE;
>>
>
> Sei que pode não fazer diferença, mas sempre é motivo de divergências no
> banco de dados e loucuras em geral durante a implementação, mas você já
> tentou utilizar o tipo "STABLE" ao invés de "VOLATILE"?
> Sua função não faz modificações no banco, portanto ela não é volátil.
>
> Pode não dar em nada, porque já vi os tipos de função apresentar
> diferentes comportamentos em diferentes bancos/quantidade de
> registros/estatísticas, mas né, não custa fazer da forma correta.
>
> []'s
>

Favor ignorar a última mensagem.. Fiz o teste aqui e não resolve o
problema. O problema está no fetch mesmo, que não incrementa o cursor e
fica dando voltas no mesmo registro, aparentemente.
Já cogitaste utilizar um type, fazendo uma função com tipo de retorno SETOF
deste type?
Deste modo funcionaria mais ou menos como você quer, porém realizando um
loop em um record.

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Rafael Fialho]

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 query está sendo executada e não
> sai disso. O objetivo é agilizar o retorno destes registros.
>
> ()
> $BODY$
>LANGUAGE 'plpgsql' VOLATILE;
>

Sei que pode não fazer diferença, mas sempre é motivo de divergências no
banco de dados e loucuras em geral durante a implementação, mas você já
tentou utilizar o tipo "STABLE" ao invés de "VOLATILE"?
Sua função não faz modificações no banco, portanto ela não é volátil.

Pode não dar em nada, porque já vi os tipos de função apresentar diferentes
comportamentos em diferentes bancos/quantidade de registros/estatísticas,
mas né, não custa fazer da forma correta.

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Glauco Torres]

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 com registros em Cache, mas hoje em
> dia com o numero de informações que trabalhamos não é viável.
> Você não só prejudica o usuário da maquina que quer todos esses registros,
> como toda a rede.
> Imagino que você deve estar usando Query.Filter, é rápido quando o grid já
> está carregado, mas com o tempo sua aplicação vai começar a travar legal.
> Eu já tive este problema com usuários que queriam trabalhar com esse monte
> de registros abertos, mas resolvi encaram de frente e mudar essa política.
> Hoje meus Grids, trazem os 50 ultimos registros, e a tela de pesquisa dá a
> opção pro cara trazer os registros conforme precisa, mas nesta pesquisa ele
> pode trazer 1 ou todos os registros... mas aí ele já sabe que se puxar
> todos os sistema vai ficar mais lento, ou seja transferi essa
> responsabilidade pra ele.
> De inicio como trago somente os 50 ultimos em todas as maquinas, o
> servidor não sobrecarrega nem a rede.
> Com o tempo o usuário acaba aprendendo a trabalhar com menos registros e
> nem sente falta dos famigerados (todos registros).
> Ou seja, a opção está lá, mas ele usa quando quer.
> Sinceramente, ainda não consegui encontrar uma boa explicação (ou
> argumento) para se trabalhar com tantos registros assim.
>
> A questão de trazer registros conforme um filtro?
> Um select resolve isso tranquilamente e você trabalha com dados em
> tempo real, não corre o risco de informações obsoletas.
>
> Outra coisa que estou estudando é trabalhar como o facebook quando carrega
> os posts, conforme o cara vai chegando proximo dos ultimos registros vou
> trazendo mais.
> Mas devemos lembrar que o limite não está somente no servidor e rede, mas
> na maquina local, pois quando você traz essas informações e não cabe na
> memoria ele passa a fazer uso da memoria virtual (no disco) ai não tem
> jeito, fica lento mesmo.
>
> Marcelo Silva
>
>
>
>
Nossa você conseguiu bagunçar toda uma tread... Parabéns!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Marcelo Silva]

Olha, vou te atazanar neste assunto 
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 com registros em Cache, mas hoje em dia 
com o numero de informações que trabalhamos não é viável.
Você não só prejudica o usuário da maquina que quer todos esses registros, como 
toda a rede.
Imagino que você deve estar usando Query.Filter, é rápido quando o grid já está 
carregado, mas com o tempo sua aplicação vai começar a travar legal.
Eu já tive este problema com usuários que queriam trabalhar com esse monte de 
registros abertos, mas resolvi encaram de frente e mudar essa política.
Hoje meus Grids, trazem os 50 ultimos registros, e a tela de pesquisa dá a 
opção pro cara trazer os registros conforme precisa, mas nesta pesquisa ele 
pode trazer 1 ou todos os registros... mas aí ele já sabe que se puxar todos os 
sistema vai ficar mais lento, ou seja transferi essa responsabilidade pra ele.
De inicio como trago somente os 50 ultimos em todas as maquinas, o servidor não 
sobrecarrega nem a rede.
Com o tempo o usuário acaba aprendendo a trabalhar com menos registros e nem 
sente falta dos famigerados (todos registros).
Ou seja, a opção está lá, mas ele usa quando quer.
Sinceramente, ainda não consegui encontrar uma boa explicação (ou argumento) 
para se trabalhar com tantos registros assim.

A questão de trazer registros conforme um filtro?
Um select resolve isso tranquilamente e você trabalha com dados em tempo 
real, não corre o risco de informações obsoletas.

Outra coisa que estou estudando é trabalhar como o facebook quando carrega os 
posts, conforme o cara vai chegando proximo dos ultimos registros vou trazendo 
mais.
Mas devemos lembrar que o limite não está somente no servidor e rede, mas na 
maquina local, pois quando você traz essas informações e não cabe na memoria 
ele passa a fazer uso da memoria virtual (no disco) ai não tem jeito, fica 
lento mesmo.

Marcelo Silva




From: Junior Miranda 
Sent: Friday, March 13, 2015 1:47 PM
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
Especializando em Sistemas Computacionais
E-mail: flmirandajun...@gmail.com
Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020


Em 13 de março de 2015 13:43, Vinicius Santos  
escreveu:

  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 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 Miranda  
escreveu: 


  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 por 
que nem sem ele consegui retornar os registros.


  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:27, Matheus de Oliveira 
 escreveu:


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...

Poucas informações para que possamos ajudar. Você diz pra fazer de X em 
X, mas você não fez isso. Pode compartilhar conosco o uso de tantos registros 
assim?


Atenciosamente,

-- 

Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral





___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Matheus de Oliveira]

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 aplicação fizesse a
navegação.

Outro método seria passar o refcursor para aplicação, assim ela abre a
primeira vez e retorna uma certa quantidade, e nas demais ela só navega e
retorna.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Junior Miranda]

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 de março de 2015 13:57, Matheus de Oliveira  escreveu:

>
> 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 lentidão na abertura da pesquisa. Não fetch X em
>> X por que nem sem ele consegui retornar os registros.
>
>
> Ok. Como funciona sua aplicação?
>
> Se for uma aplicação desktop que mantém a conexão aberta com o banco
> (funcional, mas não escala), você pode abrir o cursor e navegar nele
> enquanto o usuário for descendo no grid. Mas você não vai conseguir fazer
> isso de forma satisfatória usando uma função PL/pgSQL, e o cursor deve ou
> ser aberto diretamente na aplicação ou sua função retornar um refcursor. De
> qualquer forma a aplicação deve se encarregar de navegar nesse cursor
> (claro que você pode usar funções para carregar, mas não vejo vantagens
> nisso).
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Matheus de Oliveira]

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 lentidão na abertura da pesquisa. Não fetch X em
> X por que nem sem ele consegui retornar os registros.


Ok. Como funciona sua aplicação?

Se for uma aplicação desktop que mantém a conexão aberta com o banco
(funcional, mas não escala), você pode abrir o cursor e navegar nele
enquanto o usuário for descendo no grid. Mas você não vai conseguir fazer
isso de forma satisfatória usando uma função PL/pgSQL, e o cursor deve ou
ser aberto diretamente na aplicação ou sua função retornar um refcursor. De
qualquer forma a aplicação deve se encarregar de navegar nesse cursor
(claro que você pode usar funções para carregar, mas não vejo vantagens
nisso).

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Paulo Vitor Bettini de Albuqerque Lima]

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 registros, ou de 10 em
10, e assim por diante.



> 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:43, Vinicius Santos <
> vinicius.santos.li...@gmail.com> escreveu:
>
> 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 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 Miranda 
>>> escreveu:
>>>
>>> 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 por que nem sem ele consegui retornar os registros.

 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:27, Matheus de Oliveira <
 matioli.math...@gmail.com> escreveu:

>
> 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...
>
>
> Poucas informações para que possamos ajudar. Você diz pra fazer de X
> em X, mas você não fez isso. Pode compartilhar conosco o uso de tantos
> registros assim?
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Junior Miranda]

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 *
*Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020


Em 13 de março de 2015 13:43, Vinicius Santos <
vinicius.santos.li...@gmail.com> escreveu:

> 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 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 Miranda 
>> escreveu:
>>
>> 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 por que nem sem ele consegui retornar os registros.
>>>
>>> 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:27, Matheus de Oliveira <
>>> matioli.math...@gmail.com> escreveu:
>>>

 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...


 Poucas informações para que possamos ajudar. Você diz pra fazer de X em
 X, mas você não fez isso. Pode compartilhar conosco o uso de tantos
 registros assim?

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


>>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Vinicius Santos]

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 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 Miranda 
> escreveu:
>
> 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 por que nem sem ele consegui retornar os registros.
>>
>> 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:27, Matheus de Oliveira <
>> matioli.math...@gmail.com> escreveu:
>>
>>>
>>> 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...
>>>
>>>
>>> Poucas informações para que possamos ajudar. Você diz pra fazer de X em
>>> X, mas você não fez isso. Pode compartilhar conosco o uso de tantos
>>> registros assim?
>>>
>>> Atenciosamente,
>>> --
>>> Matheus de Oliveira
>>> Analista de Banco de Dados
>>> Dextra Sistemas - MPS.Br nível F!
>>> www.dextra.com.br/postgres
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Junior Miranda]

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 Miranda 
escreveu:

> 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 por que nem sem ele consegui retornar os registros.
>
> 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:27, Matheus de Oliveira <
> matioli.math...@gmail.com> escreveu:
>
>>
>> 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...
>>
>>
>> Poucas informações para que possamos ajudar. Você diz pra fazer de X em
>> X, mas você não fez isso. Pode compartilhar conosco o uso de tantos
>> registros assim?
>>
>> Atenciosamente,
>> --
>> Matheus de Oliveira
>> Analista de Banco de Dados
>> Dextra Sistemas - MPS.Br nível F!
>> www.dextra.com.br/postgres
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[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 lentidão na abertura da pesquisa. Não fetch X em
X por que nem sem ele consegui retornar os registros.

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:27, Matheus de Oliveira  escreveu:

>
> 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...
>
>
> Poucas informações para que possamos ajudar. Você diz pra fazer de X em X,
> mas você não fez isso. Pode compartilhar conosco o uso de tantos registros
> assim?
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Matheus de Oliveira]

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...


Poucas informações para que possamos ajudar. Você diz pra fazer de X em X,
mas você não fez isso. Pode compartilhar conosco o uso de tantos registros
assim?

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[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...

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:10, Matheus de Oliveira  escreveu:

>
> 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ção SQL, assim se
> filtrar por fora ela pode ser otimizada.
>
> Algo do tipo:
>
> CREATE OR REPLACE FUNCTION fn_busca_Produto()
>RETURNS TABLE(oprd_id produto.prd_id%TYPE, oprd_nome
> produto.prd_nome%TYPE) As
> $BODY$
> SELECT prd_id, prd_nome FROM produto;
> $BODY$
>LANGUAGE SQL STABLE;
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Matheus de Oliveira]

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ção SQL, assim se
filtrar por fora ela pode ser otimizada.

Algo do tipo:

CREATE OR REPLACE FUNCTION fn_busca_Produto()
   RETURNS TABLE(oprd_id produto.prd_id%TYPE, oprd_nome
produto.prd_nome%TYPE) As
$BODY$
SELECT prd_id, prd_nome FROM produto;
$BODY$
   LANGUAGE SQL STABLE;

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[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??

Júnior Miranda
*Analista de Sistemas*
*Especializando em Sistemas Computacionais*
*E-mail: flmirandajun...@gmail.com *
*Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020


2015-03-13 12:38 GMT-03:00 Matheus de Oliveira :

>
> 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
>>FETCH cur_produtos INTO oprd_id, oprd_nome;
>>RETURN NEXT;
>>  END LOOP;
>>  CLOSE cur_produtos;
>> END;
>> $BODY$
>>LANGUAGE 'plpgsql' VOLATILE;
>>
>
>
> Por que não executar a consulta diretamente? Você quer mesmo todos
> resultados sem nenhum filtro?
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Matheus de Oliveira]

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
>FETCH cur_produtos INTO oprd_id, oprd_nome;
>RETURN NEXT;
>  END LOOP;
>  CLOSE cur_produtos;
> END;
> $BODY$
>LANGUAGE 'plpgsql' VOLATILE;
>


Por que não executar a consulta diretamente? Você quer mesmo todos
resultados sem nenhum filtro?

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Consulta lenta

[Junior Miranda]

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 retorno destes registros.

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
   FETCH cur_produtos INTO oprd_id, oprd_nome;
   RETURN NEXT;
 END LOOP;
 CLOSE cur_produtos;
END;
$BODY$
   LANGUAGE 'plpgsql' VOLATILE;


Júnior Miranda
*Analista de Sistemas*
*Especializando em Sistemas Computacionais*
*E-mail: flmirandajun...@gmail.com *
*Tel.: *(75) 9191-1678/ 34143042/ 34143149/ 34143020
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Luiz Poleti]

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 pouco o retorno das 
consultas (imagina em tabelas grandes)


Testando FillFactor

A) table espace

1) Criei table space

CREATE TABLESPACE tbs_estrutura
  OWNER role_user
  LOCATION '/tablespace/conteudoestutura';

CREATE TABLESPACE tbs_estruturas_id
  OWNER role_user
  LOCATION '/tablespace/estruturas_id';


B) Estruturas e Dados

1) Criei uma tabela muito simples

CREATE TABLE teste
(
  id integer NOT NULL,
  nome text,
  nota integer NOT NULL
)
WITH (
  OIDS=FALSE
)
TABLESPACE tbs_estrutura;
obs: Query returned successfully with no result in 292 ms.

2) Coloquei a primary key com fillfactor padrão (90)

ALTER TABLE teste
ADD CONSTRAINT  pk_teste_id PRIMARY KEY (id)
WITH (FILLFACTOR=90)
USING INDEX TABLESPACE tbs_estruturas_id;
obs: Query returned successfully with no result in 242 ms.


3) Adicionei algumas alguns registros sequencias

INSERT INTO teste (id, nome, nota) VALUES (generate_series(1,1), 
'nome ' || generate_series(1,1), round(CAST (random()*100 AS 
NUMERIC),0));

Query returned successfully: 1 rows affected, 67200 ms execution time.

4) Select
select id, nome, nota from teste where id=5000;
Total query runtime: 32 ms.

5) Alterando o fillfactor (10) (Repetindo passoas 1 - 3 )
Obs:
insert: Query returned successfully: 1 rows affected, 3653 ms 
execution time.

select: Total query runtime: 23 ms.

6) refazendo todos os passos, porem colocando os dados primeiros (insert 
-> add constraint) (fillfactor 10)
insert: Query returned successfully: 1 rows affected, 192 ms 
execution time.

add contratint:  Query returned successfully with no result in 241 ms.
select: Total query runtime: 35 ms.
tamanho dos indices: 984 KB

7) refazendo todos os passos, porem colocando os dados primeiros (insert 
-> add constraint) (fillfactor 100)
insert: Query returned successfully: 1 rows affected, 221 ms 
execution time.

add contratint:  Query returned successfully with no result in 221 ms.
select: Total query runtime: 55 ms.
tamanho dos indices: 792 KB

Para verificar o tamanho da table space
-SELECT pg_size_pretty(pg_tablespace_size('tbs_estruturas_id'));

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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 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 daria pra responder sem levantar outraa questoes...
>
> Por isso mesmo não cabe dar dicas às cegas, sem entender nem o
> problema original, nem o mecanismo da dica dada.
>
>
> > parabena por ser o dono da verdade...
>
> No caso do Euler, com propriedade.  Ele é uma das pessoas que mais
> entende aqui, com prestígio inclusive fora do Brasil.  Você pode até
> desejar que ele fale de outra maneira, mas vai ter de argumentar para
> lhe tirar a razão.
>
>
> > pois entendo mto bem do fillfactor
>
> Não parece.
>
>
> > e perguntei pra ele testar...
>
> Sim, mas por quê?  Se cada um der uma dica sem justificativa, o
> usuário vai desistir da lista.  Por isso pedimos fundamentos.
>
>
> > como nao se pronunciou vou mostrar q isto eh quesito de
> > lentidao...
>
> O que isso quer dizer?  Mostrar o que exatamente, e como?
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Guimarães Faria Corcete DUTRA , Leandro]

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 daria pra responder sem levantar outraa questoes...

Por isso mesmo não cabe dar dicas às cegas, sem entender nem o
problema original, nem o mecanismo da dica dada.


> parabena por ser o dono da verdade...

No caso do Euler, com propriedade.  Ele é uma das pessoas que mais
entende aqui, com prestígio inclusive fora do Brasil.  Você pode até
desejar que ele fale de outra maneira, mas vai ter de argumentar para
lhe tirar a razão.


> pois entendo mto bem do fillfactor

Não parece.


> e perguntei pra ele testar...

Sim, mas por quê?  Se cada um der uma dica sem justificativa, o
usuário vai desistir da lista.  Por isso pedimos fundamentos.


> como nao se pronunciou vou mostrar q isto eh quesito de
> lentidao...

O que isso quer dizer?  Mostrar o que exatamente, e como?


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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 19/02/2014 14:40, "Euler Taveira"  escreveu:

> 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 rapidamente em memoria e processada mais
> > rapidamente?
> >
> Dá para parar com o top-posting? Siga as regras [1] da lista! Essa será
> a minha última resposta caso insista nisso.
>
> Quanto a sua resposta, você precisa entender melhor o conceito de
> fillfactor [2][3]. Há fillfactor tanto para índices quanto para tabelas.
> E, repetindo novamente, quanto mais páginas mais I/O será utilizada,
> portanto, ao invés de acelerar as buscas (o ideia do fillfactor é tentar
> manter registros atualizados na mesma página que o registro original
> está) você aumentará o tempo de consultas inversamente proporcional ao
> valor do fillfactor escolhido. (Não estou considerando o efeito da cache
> do SO). Novamente, a conclusão é: só utilize fillfactor se (i) souber
> para que serve e (ii) a taxa de atualização de um *mesmo* registro for
> alta.
>
>
> [1] http://www.postgresql.org.br/RegrasLista
> [2]
>
> file:///home/euler/pg932/share/doc/postgresql/html/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
> [3]
>
> http://www.postgresql.org/docs/9.3/static/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Euler Taveira]

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 rapidamente em memoria e processada mais
> rapidamente?
> 
Dá para parar com o top-posting? Siga as regras [1] da lista! Essa será
a minha última resposta caso insista nisso.

Quanto a sua resposta, você precisa entender melhor o conceito de
fillfactor [2][3]. Há fillfactor tanto para índices quanto para tabelas.
E, repetindo novamente, quanto mais páginas mais I/O será utilizada,
portanto, ao invés de acelerar as buscas (o ideia do fillfactor é tentar
manter registros atualizados na mesma página que o registro original
está) você aumentará o tempo de consultas inversamente proporcional ao
valor do fillfactor escolhido. (Não estou considerando o efeito da cache
do SO). Novamente, a conclusão é: só utilize fillfactor se (i) souber
para que serve e (ii) a taxa de atualização de um *mesmo* registro for alta.


[1] http://www.postgresql.org.br/RegrasLista
[2]
file:///home/euler/pg932/share/doc/postgresql/html/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
[3]
http://www.postgresql.org/docs/9.3/static/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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?
Em 19/02/2014 04:04, "Euler Taveira"  escreveu:

> 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 banco seria bom pra analise. Tente com os
> > seguintes numeros, 25, 50, 75
> >
> [Sem top-posting isso bagunça o histórico...]
>
> INSERTs? Como eu disse no outro email, fillfactor *não* tem haver com
> muitas inserções e sim com *muitas* atualizações.
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Euler Taveira]

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 banco seria bom pra analise. Tente com os
> seguintes numeros, 25, 50, 75
> 
[Sem top-posting isso bagunça o histórico...]

INSERTs? Como eu disse no outro email, fillfactor *não* tem haver com
muitas inserções e sim com *muitas* atualizações.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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 numeros, 25, 50, 75
Em 19/02/2014 02:07, "Euler Taveira"  escreveu:

> 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ção); esse não é um deles (a não ser que o OP diga o contrário).
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Euler Taveira]

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ção); esse não é um deles (a não ser que o OP diga o contrário).


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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 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 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Guimarães Faria Corcete DUTRA , Leandro]

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 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Renato Poleti]

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, 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 registros
>>>
>>> explain:
>>> "Nested Loop  (cost=0.00..12474.40 rows=1 width=46) (actual
>>> time=24228.265..45081.510 rows=1 loops=1)"
>>> "  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
>>> "  Rows Removed by Join Filter: 1025"
>>> "  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao
>>>  (cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513
>>> loops=1)"
>>> "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)"
>>> "Filter: (hisnot = 359921)"
>>> "Rows Removed by Filter: 669822"
>>> "Total runtime: 45081.543 ms"
>>>
>>> pq será que isto demora 45 segundos? Algum indice não está sendo usado?
>>>
>>>  Um detalhe interessante que vi agora: se eu tirar a condição and
>> fasava=81 a consulta demora 71 ms
>>
>>  Resolvi. O indice abaixo caiu pra 17 ms
>
> CREATE INDEX tac_nota_hisnot_idx
>   ON tac_nota
>   USING btree
>   (hisnot);
>
>
>
> --
>   .~.Prof. Cleverson B. Klettenberg
>  / v \   prof_clever...@uniguacu.edu.br
> /(   )\
>  ^^-^^   Seja Livre!
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Prof. Cleverson]

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 registros
a tabela de notas tem 66 registros

explain:
"Nested Loop  (cost=0.00..12474.40 rows=1 width=46) (actual 
time=24228.265..45081.510 rows=1 loops=1)"

"  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
"  Rows Removed by Join Filter: 1025"
"  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao  
(cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513 
loops=1)"

"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)"

"Filter: (hisnot = 359921)"
"Rows Removed by Filter: 669822"
"Total runtime: 45081.543 ms"

pq será que isto demora 45 segundos? Algum indice não está sendo usado?

Um detalhe interessante que vi agora: se eu tirar a condição and 
fasava=81 a consulta demora 71 ms



Resolvi. O indice abaixo caiu pra 17 ms

CREATE INDEX tac_nota_hisnot_idx
  ON tac_nota
  USING btree
  (hisnot);



--
  .~.Prof. Cleverson B. Klettenberg
 / v \   prof_clever...@uniguacu.edu.br
/(   )\
 ^^-^^   Seja Livre!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Prof. Cleverson]

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. 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 registros

explain:
"Nested Loop  (cost=0.00..12474.40 rows=1 width=46)
(actual time=24228.265..45081.510 rows=1 loops=1)"
"  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
"  Rows Removed by Join Filter: 1025"
"  ->  Index Scan using tac_avaliacao_fasava_idx on
tac_avaliacao  (cost=0.00..4.55 rows=1 width=29) (actual
time=0.020..1.927 rows=513 loops=1)"
"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)"
"Filter: (hisnot = 359921)"
"Rows Removed by Filter: 669822"
"Total runtime: 45081.543 ms"

pq será que isto demora 45 segundos? Algum indice não está
sendo usado?

Um detalhe interessante que vi agora: se eu tirar a condição
and fasava=81 a consulta demora 71 ms


"fasava" seria um campo da tabela "tac_nota" e "hisnot" um campo
da tabela "tac_avaliacao", certo?


Perdão, me enganei na visualização do plano.
Seria exatamente o oposto disso.

1. Existe índice pro campo "hisnot" da tabela "tac_nota"?
2. Existe índice pro campo "avanot" da tabela "tac_nota"?

[]'s


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Indice não, mas ambos são chave estrangeira.

--
  .~.Prof. Cleverson B. Klettenberg
 / v \   prof_clever...@uniguacu.edu.br
/(   )\
 ^^-^^   Seja Livre!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Prof. Cleverson]

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:
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 rows=1 width=46) (actual
time=24228.265..45081.510 rows=1 loops=1)"
"  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
"  Rows Removed by Join Filter: 1025"
"  ->  Index Scan using tac_avaliacao_fasava_idx on
tac_avaliacao  (cost=0.00..4.55 rows=1 width=29) (actual
time=0.020..1.927 rows=513 loops=1)"
"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)"
"Filter: (hisnot = 359921)"
"Rows Removed by Filter: 669822"
"Total runtime: 45081.543 ms"

pq será que isto demora 45 segundos? Algum indice não está
sendo usado?

Um detalhe interessante que vi agora: se eu tirar a condição and
fasava=81 a consulta demora 71 ms


"fasava" seria um campo da tabela "tac_nota" e "hisnot" um campo da 
tabela "tac_avaliacao", certo?



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Sim, fasava é um campo de tac_avaliação. Ambos os campos do where são 
chaves estrangeiras.



--
  .~.Prof. Cleverson B. Klettenberg
 / v \   prof_clever...@uniguacu.edu.br
/(   )\
 ^^-^^   Seja Livre!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Marcos - GMail]

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 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 rows=1 width=46) (actual
> time=24228.265..45081.510 rows=1 loops=1)"
> "  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
> "  Rows Removed by Join Filter: 1025"
> "  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao
>  (cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513
> loops=1)"
> "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)"
> "Filter: (hisnot = 359921)"
> "Rows Removed by Filter: 669822"
> "Total runtime: 45081.543 ms"
>
> pq será que isto demora 45 segundos? Algum indice não está sendo usado?
>
> --
>   .~.Prof. Cleverson B. Klettenberg
>  / v \   prof_clever...@uniguacu.edu.br
> /(   )\
>  ^^-^^   Seja Livre!
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Vinícius Aquino do Vale]

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 registro
fasava=81, tente criar um indice para este campo, de preferência verifique
outras consultas que utilizam o seq scan para essas mesmas tabelas e tente
criar um indice composto. Deve amenizar a demora da consulta.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Rafael Fialho Corrêa]

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 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 rows=1 width=46) (actual
>>> time=24228.265..45081.510 rows=1 loops=1)"
>>> "  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
>>> "  Rows Removed by Join Filter: 1025"
>>> "  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao
>>>  (cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513
>>> loops=1)"
>>> "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)"
>>> "Filter: (hisnot = 359921)"
>>> "Rows Removed by Filter: 669822"
>>> "Total runtime: 45081.543 ms"
>>>
>>> pq será que isto demora 45 segundos? Algum indice não está sendo usado?
>>>
>>>  Um detalhe interessante que vi agora: se eu tirar a condição and
>> fasava=81 a consulta demora 71 ms
>
>
> "fasava" seria um campo da tabela "tac_nota" e "hisnot" um campo da tabela
> "tac_avaliacao", certo?
>

Perdão, me enganei na visualização do plano.
Seria exatamente o oposto disso.

1. Existe índice pro campo "hisnot" da tabela "tac_nota"?
2. Existe índice pro campo "avanot" da tabela "tac_nota"?

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Rafael Fialho Corrêa]

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
>> 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 rows=1 width=46) (actual
>> time=24228.265..45081.510 rows=1 loops=1)"
>> "  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
>> "  Rows Removed by Join Filter: 1025"
>> "  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao
>>  (cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513
>> loops=1)"
>> "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)"
>> "Filter: (hisnot = 359921)"
>> "Rows Removed by Filter: 669822"
>> "Total runtime: 45081.543 ms"
>>
>> pq será que isto demora 45 segundos? Algum indice não está sendo usado?
>>
>>  Um detalhe interessante que vi agora: se eu tirar a condição and
> fasava=81 a consulta demora 71 ms


"fasava" seria um campo da tabela "tac_nota" e "hisnot" um campo da tabela
"tac_avaliacao", certo?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta

[Prof. Cleverson]

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 registros

explain:
"Nested Loop  (cost=0.00..12474.40 rows=1 width=46) (actual 
time=24228.265..45081.510 rows=1 loops=1)"

"  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
"  Rows Removed by Join Filter: 1025"
"  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao  
(cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513 
loops=1)"

"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)"

"Filter: (hisnot = 359921)"
"Rows Removed by Filter: 669822"
"Total runtime: 45081.543 ms"

pq será que isto demora 45 segundos? Algum indice não está sendo usado?

Um detalhe interessante que vi agora: se eu tirar a condição and 
fasava=81 a consulta demora 71 ms


--
  .~.Prof. Cleverson B. Klettenberg
 / v \   prof_clever...@uniguacu.edu.br
/(   )\
 ^^-^^   Seja Livre!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] consulta lenta

[Prof. Cleverson]

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 rows=1 width=46) (actual 
time=24228.265..45081.510 rows=1 loops=1)"

"  Join Filter: (tac_avaliacao.codava = tac_nota.avanot)"
"  Rows Removed by Join Filter: 1025"
"  ->  Index Scan using tac_avaliacao_fasava_idx on tac_avaliacao  
(cost=0.00..4.55 rows=1 width=29) (actual time=0.020..1.927 rows=513 
loops=1)"

"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)"

"Filter: (hisnot = 359921)"
"Rows Removed by Filter: 669822"
"Total runtime: 45081.543 ms"

pq será que isto demora 45 segundos? Algum indice não está sendo usado?

--
  .~.Prof. Cleverson B. Klettenberg
 / v \   prof_clever...@uniguacu.edu.br
/(   )\
 ^^-^^   Seja Livre!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Mozart Hasse]

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 atualizações, pode fazer alguma diferença.

> A tabela tem a seguinte estrutura e índice:
>
> CREATE TABLE history (
>   itemid bigint NOT NULL DEFAULT (0)::bigint,
>   clock integer NOT NULL DEFAULT 0,
>   "value" numeric(16,4) NOT NULL DEFAULT 0.
> ) WITH (OIDS=TRUE);

Tire esse maldito OIDS=TRUE, só ocupa espaço. Se alguém disser que usa esse 
treco, convença-o a não usar. Como teu gargalo é I/O e o teu registro é 
pequeno, isso pode fazer dar uma boa diferença.

> CREATE INDEX history_1  ON.history
>   USING btree  (itemid, clock);

Creio que a consulta nem use esse índice, tente criar uma PK ou declare esse 
índice como UNIQUE (se estes campos o forem de fato). Não sei o PostgreSQL, 
mas um banco de dados inteligente se aproveitaria disso.
Usar as tabelas de estatísticas não te dará uma estimativa exata ou vai 
mudar o ponto de lentidão, veja se é aplicável a seu caso.
Esse índice é muito esquisito, você tem certeza que alguma aplicação faz uso 
dele?! COm um índice a menos, a atualização e o vacuum/analyze ficariam 
menos piores.


Mozart 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Tiago Adami]

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
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Tiago Adami]

Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
 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 horário em que é executada.
>
> A tabela history possui em média 87 milhões de registros.
>
> É uma tabela que sofre muito insert/update/delete.
>
> (corte)
>

Já precisei de algo parecido em mais de uma tabela (auditoria), e para
reduzir ao máximo os problemas de desempenho foi criada uma tabela de
contadores que é atualizada a cada operação.

Adaptei o script para a sua tabela, espero que possa ajudá-la.

-- INÍCIO DO SCRIPT
-- ***
-- PARA A COLUNA counter_type:
-- ***
-- 'ROW' = Número de Linhas, 'DEL' = Delete, 'UPD' = Update, 'INS' = Insert
CREATE TABLE table_counter (
table_name VARCHAR(100) not null,
counter_type CHAR(3) not null,
counter_value INTEGER not null default 0
);
--
ALTER TABLE table_counter ADD PRIMARY KEY( table_name, counter_type );
--
-- Adiciona pela primeira vez o total de registros na tabela
--
INSERT INTO table_counter( table_name, counter_type, counter_value )
VALUES( 'history', 'ROW', ( SELECT COUNT(*) FROM history ) );
--
CREATE FUNCTION trf_ins_history_count()
RETURNS TRIGGER AS
$BODY$
DECLARE
_RS RECORD;
i_count INTEGER;
BEGIN
SELECT INTO _RS counter_value FROM table_counter WHERE table_name =
'history' AND counter_type = 'INS';

IF NOT FOUND THEN
INSERT INTO table_counter( table_name, counter_type, 
counter_value )
VALUES( 'history', 'INS', 0 );
i_count := 1;
ELSE
i_count := _RS.counter_value;
i_count := i_count + 1;
END IF;

-- Atualiza a quantidade de INSERTs que a tabela recebeu
UPDATE table_counter SET counter_value = i_count WHERE table_name =
'history' AND counter_type = 'INS';

-- Atualiza o número de registros
-- Deve existir um TRIGGER para DELETE que remova uma unidade a cada
registro eliminado.
UPDATE table_counter SET counter_value = counter_value +1 WHERE
table_name = 'history' AND counter_type = 'ROW';

RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
--
CREATE TRIGGER tr_ins_history AFTER INSERT ON history FOR EACH ROW
EXECUTE PROCEDURE trf_ins_history_count();
--
CREATE FUNCTION trf_upd_history_count()
RETURNS TRIGGER AS
$BODY$
DECLARE
_RS RECORD;
i_count INTEGER;
BEGIN
SELECT INTO _RS counter_value FROM table_counter WHERE table_name =
'history' AND counter_type = 'UPD';

IF NOT FOUND THEN
INSERT INTO table_counter( table_name, counter_type, 
counter_value )
VALUES( 'history', 'UPD', 0 );
i_count := 1;
ELSE
i_count := _RS.counter_value;
i_count := i_count + 1;
END IF;

-- Atualiza a quantidade de UPDATES que a tabela recebeu
UPDATE table_counter SET counter_value = i_count WHERE table_name =
'history' AND counter_type = 'UPD';

-- NÃO Atualiza o número de registros

RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
--
CREATE TRIGGER tr_upd_history AFTER UPDATE ON history FOR EACH ROW
EXECUTE PROCEDURE trf_upd_history_count();
--
CREATE FUNCTION trf_del_history_count()
RETURNS TRIGGER AS
$BODY$
DECLARE
_RS RECORD;
i_count INTEGER;
BEGIN
SELECT INTO _RS counter_value FROM table_counter WHERE table_name =
'history' AND counter_type = 'DEL';

IF NOT FOUND THEN
INSERT INTO table_counter( table_name, counter_type, 
counter_value )
VALUES( 'history', 'DEL', 0 );
i_count := 1;
ELSE
i_count := _RS.counter_value;
i_count := i_count + 1;
END IF;

-- Atualiza a quantidade de INSERTs que a tabela recebeu
UPDATE table_counter SET counter_value = i_count WHERE table_name =
'history' AND counter_type = 'DEL';

-- Atualiza o número de registros
UPDATE table_counter SET counter_value = counter_value -1 WHERE
table_name = 'history' AND counter_type = 'ROW';

RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
--
CREATE TRIGGER tr_del_history AFTER DELETE ON history FOR EACH ROW
EXECUTE PROCEDURE trf_del_history_count();
-- FIM DO SCRIPT




-- 
TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[JotaComm]

Olá,

Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
escreveu:

>  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.
>

Uma forma de você descobrir é:

SELECT reltuples FROM pg_class WHERE relname='history';

Para o resultado preciso o ideal é executar um ANALYZE history antes.

>
>
> 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.
>
>
>
> Estou utilizando postgresql 8.4.4
>
>
>
> A tabela tem a seguinte estrutura e índice:
>
>
>
> CREATE TABLE history
>
> (
>
>   itemid bigint NOT NULL DEFAULT (0)::bigint,
>
>   clock integer NOT NULL DEFAULT 0,
>
>   "value" numeric(16,4) NOT NULL DEFAULT 0.
>
> )
>
> WITH (OIDS=TRUE);
>
>
>
> -- Index: history_1
>
>
>
> CREATE INDEX history_1  ON.history
>
>   USING btree  (itemid, clock);
>
>
>
>
>
> *Mônica***
>
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

Atenciosamente
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta

[Alexsander Rosa]

Serve um SELECT pg_relation_size('history') / tamanho do registro ?

Em 28 de julho de 2010 15:33, Monica Ferrari Villarino
escreveu:

>  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 milhões* de registros.
>
> É uma tabela que sofre muito insert/update/delete.
>
> Faço analyze e reindexação semanalmente.
>
>
>
> Estou utilizando postgresql 8.4.4
>
>
>
> A tabela tem a seguinte estrutura e índice:
>
>
>
> CREATE TABLE history
>
> (
>
>   itemid bigint NOT NULL DEFAULT (0)::bigint,
>
>   clock integer NOT NULL DEFAULT 0,
>
>   "value" numeric(16,4) NOT NULL DEFAULT 0.
>
> )
>
> WITH (OIDS=TRUE);
>
>
>
> -- Index: history_1
>
>
>
> CREATE INDEX history_1  ON.history
>
>   USING btree  (itemid, clock);
>
>
>
>
>
> *Mônica***
>
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

"Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude."
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Consulta lenta

[Monica Ferrari Villarino]

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 milhões de registros.

É uma tabela que sofre muito insert/update/delete.

Faço analyze e reindexação semanalmente.

 

Estou utilizando postgresql 8.4.4

 

A tabela tem a seguinte estrutura e índice:

 

CREATE TABLE history

(

  itemid bigint NOT NULL DEFAULT (0)::bigint,

  clock integer NOT NULL DEFAULT 0,

  "value" numeric(16,4) NOT NULL DEFAULT 0.

)

WITH (OIDS=TRUE);

 

-- Index: history_1

 

CREATE INDEX history_1  ON.history

  USING btree  (itemid, clock);

 

 

Mônica

 

 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Shander Lyrio]

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 Voom e não meu.

Resposta em private para evitar off-topic.

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Vita Voom Support]

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ê não
> precisa ficar fazendo fetch. Se acompanhou, vai ver que ele quer
> selecionar todos os registros da tabela e ter o resultado instantaneo na
> tela, o cursor não resolve este problema.
O cursor pode retornar apenas parte dos registros do resultset, o suficiente 
para "mostrar na tela", que é exatamente o desejado. Além disso, pelo que li 
na thread, não se fala em "selecionar todos os registros e ter o resultado 
instantaneo" mas sim em "obter um desempenho melhor para essa consulta". Neste 
caso específico, o gargalo parece ser a transmissão de todos esses registros 
do servidor ao cliente. Claro, no o PostgreSQL há a complexidade adicional de 
se utilizar os cursores enquanto no Firebird não.

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 Voom e não meu.
-- 
Vita Voom Software
Support Dept.
http://www.vitavoom.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Shander Lyrio]

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 produziria um resultado que 
> satisfizesse o número de registros requisitado, ele seria enviado. É 
> exatamente para isso que existem o DECLARE e o FETCH.

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ê não 
precisa ficar fazendo fetch. Se acompanhou, vai ver que ele quer 
selecionar todos os registros da tabela e ter o resultado instantaneo na 
tela, o cursor não resolve este problema.

> Alguns drivers como o JDBC ou o pgExpress da Vita Voom implementam cursores 
> DECLARE/FETCH automáticos há muitos anos e eles são utilizados exatamente com 
> esse propósito, de tornar o retorno mais rápido e sem carregar todo o 
> conjunto 
> de registros na memória.

Eu já usei o seu driver para Delphi há muitos anos quando ainda morava 
em Belo Horizonte com a versão 7.2.(alguma coisa_) do PostGreSql e ele 
não fazia isto que o coleta está querendo, eu fui um dos que migrei do 
firebird para o PostGreSql porque a base de dados estava ficando grande 
d+ e também estava mal acostumado com este jeito de o Firebird trabalhar.

Utilizo hoje o JDBC e ele ainda não faz isto que o colega da lista está 
querendo (espero que continue não fazendo, o protocolo de comunicação do 
Firebird não é legal, isto é fato). O Firebird tem um jeito diferente de 
retornar as consultas, algo parecido como o cursor no lado servidor 
utilizando clServer do Delphi + Ado + Sql Server (acho que era isto, 
alguém do Delphi me corrija se eu estiver errado, porque eu não programo 
mais em Delphi desde que este escolheu o .Net).

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Emerson Casas Salvador]

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 tem exemplos:

http://www.postgresql.org/docs/8.3/static/sql-declare.html
http://www.postgresql.org/docs/8.3/static/sql-fetch.html

--
Esta mensagem foi verificada pelo sistema de Anti-virus da SJB Solados.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Fabricio Veiga]

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 PROTECTED]>

> 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 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 produziria um resultado que
> satisfizesse o número de registros requisitado, ele seria enviado. É
> exatamente para isso que existem o DECLARE e o FETCH.
>
> Alguns drivers como o JDBC ou o pgExpress da Vita Voom implementam cursores
> DECLARE/FETCH automáticos há muitos anos e eles são utilizados exatamente
> com
> esse propósito, de tornar o retorno mais rápido e sem carregar todo o
> conjunto
> de registros na memória.
>
> --
> Best Regards,
> Steve Howe
> http://www.vitavoom.com
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Steve Howe]

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 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 produziria um resultado que 
satisfizesse o número de registros requisitado, ele seria enviado. É 
exatamente para isso que existem o DECLARE e o FETCH.

Alguns drivers como o JDBC ou o pgExpress da Vita Voom implementam cursores 
DECLARE/FETCH automáticos há muitos anos e eles são utilizados exatamente com 
esse propósito, de tornar o retorno mais rápido e sem carregar todo o conjunto 
de registros na memória.

-- 
Best Regards,
Steve Howe
http://www.vitavoom.com


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Shander Lyrio]

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 depois ir 
enviando os registros, o que não resolveria para o que ele precisa.

> Por outro lado, carregar 420mil registros de uma vez quase nunca é uma boa 
> idéia. Não seria o caso de utilizar LIMIT e OFFSET [3] para retornar apenas 
> uma parte destes registros ?

Esta é a questão, PosGreSql não envia os registros sob demanda.

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Steve Howe]

Hello all,
> Fabricio Veiga wrote:
> > 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 Gbytes de RAM.
> > Estou ciente das configurações do servidor, porém as fazer o mesmo teste
> > em um banco de dados Interbase 6.5,
> > em outra máquina com as mesmas configurações, o tempo da consulta foi em
> > torno de 211 milisegundos.
> > Realizei a instalação padrao do PostgreSQL, sem mudanças no arquivo de
> > configurações.
> > Que parametros seriam necessário modificar para obter um desempenho
> > melhor nessa consulta ?
>
>   Acredito que você não vai obter desempenho melhor. O que acontece é que
> alguns SGDB's, e neste caso particular o Firebird, já começam a retornar
> os registros para a aplicação cliente 'a medida que são encontrados. O
> PostGreSql trabalha de forma diferente, os dados são retornados apenas
> após a consulta ser totalmente realizada. Ou seja, primeiro o PostGreSql
> encontra os 420 mil registros para depois retorná-los de uma vez,
> enquanto o Firebird vai enviando de partes em partes os registros
> encontrados. Salvo engano, o Sql Server permite configurar isto também,
> podendo trabalhar de uma forma ou de outra, mas desconheço forma de
> fazer o PostGreSql operar assim, talvez algum colega da lista já o saiba
> que queira compartilhar, alguém??
>
>   Ou seja, o PostGreSql não está preparado para usuários que não sabem o
> que querem e enviam consultas do tipo "select * from tabela" com
> relações deste tamanho.
>
>   É claro que existe o lado negro das história. Em especial full text
> search em tabelas muito grandes. Se eu fizer um limit 10 por exemplo
> para pegar os primeiros 10 registros de uma seleção, ele vai primeiro,
> selecionar todos os registros que satisfaçam à minha instrução SQL para
> somente depois limitar os 10 registros pedidos, enquanto o esperado
> seria que, assim que ele encontrasse o décimo registro ele já me
> retornar o resultado, por isso é importante sempre registringir o máximo
> os registros que quer buscar em sua SQL.
>
>   É uma limitação do PostGreSql (dentro dos meus conhecimentos),
> facilmente compensada com suas inúmeras outras facilidades.
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.

Cursores declare/fetch são bastante flexíveis e podem inclusive ser acessados 
randomicamente (não é mandatório o acesso sequencial).

Por outro lado, carregar 420mil registros de uma vez quase nunca é uma boa 
idéia. Não seria o caso de utilizar LIMIT e OFFSET [3] para retornar apenas 
uma parte destes registros ?

[1] http://www.postgresql.org/docs/8.3/static/sql-declare.html
[2] http://www.postgresql.org/docs/8.3/static/sql-fetch.html
[3] http://www.postgresql.org/docs/8.3/static/sql-select.html
-- 
Best Regards,
Steve Howe
http://www.vitavoom.com

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Diego Fernando Ormanezi Rocha]

Olá,

Não sou nenhum expert em banco.
Mas já passei por isso, e o que indico é:

1º  Verifique se existe índices

2º Faça o vacuum.
http://www.postgresql.org/docs/7.4/interactive/sql-vacuum.html

Att.

2008/11/17 Jota <[EMAIL PROTECTED]>

> 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 consulta?
>
> []s
>
>
>
> 2008/11/17 Fabricio Veiga <[EMAIL PROTECTED]>:
> > 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 Gbytes de RAM.
> > Estou ciente das configurações do servidor, porém as fazer o mesmo teste
> em
> > um banco de dados Interbase 6.5,
> > em outra máquina com as mesmas configurações, o tempo da consulta foi em
> > torno de 211 milisegundos.
> > Realizei a instalação padrao do PostgreSQL, sem mudanças no arquivo de
> > configurações.
> > Que parametros seriam necessário modificar para obter um desempenho
> melhor
> > nessa consulta ?
> >
> > Obrigado a todos!
> >
> >
> > Fabrício Veiga
> > ___
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
> >
>
>
>
> --
> João Paulo
> www.dextra.com.br/postgres
> PostgreSQL
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Diego Rocha
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Shander Lyrio]

Fabricio Veiga wrote:
> 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 Gbytes de RAM.
> Estou ciente das configurações do servidor, porém as fazer o mesmo teste 
> em um banco de dados Interbase 6.5,
> em outra máquina com as mesmas configurações, o tempo da consulta foi em 
> torno de 211 milisegundos.
> Realizei a instalação padrao do PostgreSQL, sem mudanças no arquivo de 
> configurações.
> Que parametros seriam necessário modificar para obter um desempenho 
> melhor nessa consulta ?
>  

Acredito que você não vai obter desempenho melhor. O que acontece é que 
alguns SGDB's, e neste caso particular o Firebird, já começam a retornar 
os registros para a aplicação cliente 'a medida que são encontrados. O 
PostGreSql trabalha de forma diferente, os dados são retornados apenas 
após a consulta ser totalmente realizada. Ou seja, primeiro o PostGreSql 
encontra os 420 mil registros para depois retorná-los de uma vez, 
enquanto o Firebird vai enviando de partes em partes os registros 
encontrados. Salvo engano, o Sql Server permite configurar isto também, 
podendo trabalhar de uma forma ou de outra, mas desconheço forma de 
fazer o PostGreSql operar assim, talvez algum colega da lista já o saiba 
que queira compartilhar, alguém??

Ou seja, o PostGreSql não está preparado para usuários que não sabem o 
que querem e enviam consultas do tipo "select * from tabela" com 
relações deste tamanho.

É claro que existe o lado negro das história. Em especial full text 
search em tabelas muito grandes. Se eu fizer um limit 10 por exemplo 
para pegar os primeiros 10 registros de uma seleção, ele vai primeiro, 
selecionar todos os registros que satisfaçam à minha instrução SQL para 
somente depois limitar os 10 registros pedidos, enquanto o esperado 
seria que, assim que ele encontrasse o décimo registro ele já me 
retornar o resultado, por isso é importante sempre registringir o máximo 
os registros que quer buscar em sua SQL.

É uma limitação do PostGreSql (dentro dos meus conhecimentos), 
facilmente compensada com suas inúmeras outras facilidades.

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta lenta em tabela com muitos registros

[Jota]

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 consulta?

[]s



2008/11/17 Fabricio Veiga <[EMAIL PROTECTED]>:
> 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 Gbytes de RAM.
> Estou ciente das configurações do servidor, porém as fazer o mesmo teste em
> um banco de dados Interbase 6.5,
> em outra máquina com as mesmas configurações, o tempo da consulta foi em
> torno de 211 milisegundos.
> Realizei a instalação padrao do PostgreSQL, sem mudanças no arquivo de
> configurações.
> Que parametros seriam necessário modificar para obter um desempenho melhor
> nessa consulta ?
>
> Obrigado a todos!
>
>
> Fabrício Veiga
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>



-- 
João Paulo
www.dextra.com.br/postgres
PostgreSQL
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Consulta lenta em tabela com muitos registros

[Fabricio Veiga]

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 Gbytes de RAM.
Estou ciente das configurações do servidor, porém as fazer o mesmo teste em
um banco de dados Interbase 6.5,
em outra máquina com as mesmas configurações, o tempo da consulta foi em
torno de 211 milisegundos.
Realizei a instalação padrao do PostgreSQL, sem mudanças no arquivo de
configurações.
Que parametros seriam necessário modificar para obter um desempenho melhor
nessa consulta ?

Obrigado a todos!


Fabrício Veiga
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta, ajuda interpretar explain

[José Carlos Messias]

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í seu
> problema.
>
> 2008/8/19 José Carlos Messias <[EMAIL PROTECTED]>
>>
>> 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 ON pedido.codpedido = receber.codpedido
>>  WHERE pedido.status = 4 OR pedido.status = 44 OR pedido.status = 59
>>  GROUP BY receber.codpedido;
>>
>>  QUERY PLAN
>>
>> 
>>  HashAggregate  (cost=118925.43..119785.92 rows=68839 width=8)
>>  ->  Hash Join  (cost=42712.73..114110.34 rows=963017 width=8)
>>Hash Cond: ("outer".codpedido = "inner".codpedido)
>>->  Seq Scan on receber  (cost=0.00..31467.72 rows=1432772 width=8)
>>->  Hash  (cost=39719.05..39719.05 rows=405474 width=4)
>>  ->  Bitmap Heap Scan on pedido  (cost=2560.18..39719.05
>> rows=405474 width=4)
>>Recheck Cond: ((status = 4) OR (status = 44) OR
>> (status = 59))
>>->  BitmapOr  (cost=2560.18..2560.18 rows=408907
>> width=0)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..2524.24 rows=403783 width=0)
>>Index Cond: (status = 4)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..17.97 rows=2562 width=0)
>>Index Cond: (status = 44)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..17.97 rows=2562 width=0)
>>Index Cond: (status = 59)
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta, ajuda interpretar explain

[José Carlos Messias]

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 quando faço um JOIN com uma view ou uma
subconsulta... fica muito lento mesmo.

Já estou achando que seja alguma configuração do servidor, vou passar
para vocês darem uma olhada.


2 Processadores Intel(R) Xeon(R) CPU E5320  @ 1.86GHz
4GB de RAM
3 HD's SAS de 73GB em RAID 5

S.O. Debian GNU/Linux 4.0

port = 5432
max_connections = 700
shared_buffers = 8
work_mem = 8192
max_fsm_pages = 4
max_fsm_relations = 2100




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í seu
> problema.
>
> 2008/8/19 José Carlos Messias <[EMAIL PROTECTED]>
>>
>> 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 ON pedido.codpedido = receber.codpedido
>>  WHERE pedido.status = 4 OR pedido.status = 44 OR pedido.status = 59
>>  GROUP BY receber.codpedido;
>>
>>  QUERY PLAN
>>
>> 
>>  HashAggregate  (cost=118925.43..119785.92 rows=68839 width=8)
>>  ->  Hash Join  (cost=42712.73..114110.34 rows=963017 width=8)
>>Hash Cond: ("outer".codpedido = "inner".codpedido)
>>->  Seq Scan on receber  (cost=0.00..31467.72 rows=1432772 width=8)
>>->  Hash  (cost=39719.05..39719.05 rows=405474 width=4)
>>  ->  Bitmap Heap Scan on pedido  (cost=2560.18..39719.05
>> rows=405474 width=4)
>>Recheck Cond: ((status = 4) OR (status = 44) OR
>> (status = 59))
>>->  BitmapOr  (cost=2560.18..2560.18 rows=408907
>> width=0)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..2524.24 rows=403783 width=0)
>>Index Cond: (status = 4)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..17.97 rows=2562 width=0)
>>Index Cond: (status = 44)
>>  ->  Bitmap Index Scan on idx_pedido_status
>> (cost=0.00..17.97 rows=2562 width=0)
>>Index Cond: (status = 59)
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta, ajuda interpretar explain

[Rudinei Dias]

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 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 ON pedido.codpedido = receber.codpedido
>  WHERE pedido.status = 4 OR pedido.status = 44 OR pedido.status = 59
>  GROUP BY receber.codpedido;
>
>  QUERY PLAN
>
> 
>  HashAggregate  (cost=118925.43..119785.92 rows=68839 width=8)
>  ->  Hash Join  (cost=42712.73..114110.34 rows=963017 width=8)
>Hash Cond: ("outer".codpedido = "inner".codpedido)
>->  Seq Scan on receber  (cost=0.00..31467.72 rows=1432772 width=8)
>->  Hash  (cost=39719.05..39719.05 rows=405474 width=4)
>  ->  Bitmap Heap Scan on pedido  (cost=2560.18..39719.05
> rows=405474 width=4)
>Recheck Cond: ((status = 4) OR (status = 44) OR
> (status = 59))
>->  BitmapOr  (cost=2560.18..2560.18 rows=408907
> width=0)
>  ->  Bitmap Index Scan on idx_pedido_status
> (cost=0.00..2524.24 rows=403783 width=0)
>Index Cond: (status = 4)
>  ->  Bitmap Index Scan on idx_pedido_status
> (cost=0.00..17.97 rows=2562 width=0)
>Index Cond: (status = 44)
>  ->  Bitmap Index Scan on idx_pedido_status
> (cost=0.00..17.97 rows=2562 width=0)
>Index Cond: (status = 59)
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] consulta lenta, ajuda interpretar explain

[Luiz Rafael Culik Guimaraes]

Ola

Qual a estrutura das duas tabelas envolvidas
Existe um indice por codpedido nas tabelas receber e pedido?

[]s
Luiz
- Original Message - 
From: "José Carlos Messias" <[EMAIL PROTECTED]>
To: "Comunidade PostgreSQL Brasileira" 
Sent: Tuesday, August 19, 2008 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 ON pedido.codpedido = receber.codpedido
 WHERE pedido.status = 4 OR pedido.status = 44 OR pedido.status = 59
 GROUP BY receber.codpedido;

  QUERY PLAN

 HashAggregate  (cost=118925.43..119785.92 rows=68839 width=8)
  ->  Hash Join  (cost=42712.73..114110.34 rows=963017 width=8)
Hash Cond: ("outer".codpedido = "inner".codpedido)
->  Seq Scan on receber  (cost=0.00..31467.72 rows=1432772 width=8)
->  Hash  (cost=39719.05..39719.05 rows=405474 width=4)
  ->  Bitmap Heap Scan on pedido  (cost=2560.18..39719.05
rows=405474 width=4)
Recheck Cond: ((status = 4) OR (status = 44) OR
(status = 59))
->  BitmapOr  (cost=2560.18..2560.18 rows=408907 
width=0)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..2524.24 rows=403783 width=0)
Index Cond: (status = 4)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..17.97 rows=2562 width=0)
Index Cond: (status = 44)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..17.97 rows=2562 width=0)
Index Cond: (status = 59)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] consulta lenta, ajuda interpretar explain

[José Carlos Messias]

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 ON pedido.codpedido = receber.codpedido
 WHERE pedido.status = 4 OR pedido.status = 44 OR pedido.status = 59
 GROUP BY receber.codpedido;

  QUERY PLAN

 HashAggregate  (cost=118925.43..119785.92 rows=68839 width=8)
  ->  Hash Join  (cost=42712.73..114110.34 rows=963017 width=8)
Hash Cond: ("outer".codpedido = "inner".codpedido)
->  Seq Scan on receber  (cost=0.00..31467.72 rows=1432772 width=8)
->  Hash  (cost=39719.05..39719.05 rows=405474 width=4)
  ->  Bitmap Heap Scan on pedido  (cost=2560.18..39719.05
rows=405474 width=4)
Recheck Cond: ((status = 4) OR (status = 44) OR
(status = 59))
->  BitmapOr  (cost=2560.18..2560.18 rows=408907 width=0)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..2524.24 rows=403783 width=0)
Index Cond: (status = 4)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..17.97 rows=2562 width=0)
Index Cond: (status = 44)
  ->  Bitmap Index Scan on idx_pedido_status
(cost=0.00..17.97 rows=2562 width=0)
Index Cond: (status = 59)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral