Re: [pgbr-geral] Tabela gigante - Melhoria

[Cleiton Luiz Domazak]

2015-12-14 18:17 GMT-02:00 drum.lu...@gmail.com :

> Ola...
>
> Ops... erro de digitacao galera!
> a tabela tem 88 GB (Tamanho total de 115GB) .. desculpe.
>
> * A tabela ja possui indice [1]
> ** Tamanho real da tabela [1]
>
>
> Segue link com informacoes:
>
> https://bitbucket.org/snippets/lpossamai/Gdddp
>
> Nao sei como verificar se a tabela tem somente inserts/updates ou deletes.
>

Você pode pegar essa informação com a mesma query que está no seu link de
informações, ou usar esse :

select n_tup_ins, n_tup_upd, n_tup_del from pg_stat_user_tables where
relname = 'feedlog';

Com isso você saberá qual é a operação principal na tabela.

>
> Obrigado.
>
>
> 2015-12-15 2:02 GMT+13:00 Francisco Junior :
>
>> Uma tabela com 8GB não vejo que seja uma tabela "gigante", tenho muitas
>> bases com tabela de acima de 8GB e 4GB/8GB de RAM e tem funcionado bem,
>> talvez tenha que ser feito o que o Flavio mencionou, dar uma olhada nas
>> consultas, talvez um indice já resolva seu problema, verificar se a tabela
>> não está "inchada" talvez precise de um vacuum full.
>>
>> Em 14 de dezembro de 2015 10:15, Flavio Henrique Araque Gurgel <
>> fha...@gmail.com> escreveu:
>>
>>> Oi pessoal...
 Eu tenho uma tabela de 8 GB, chamada feedlog.

 Nesta tabela eu tenho o historico do usuario dentro do sistema, TUDO o
 que ele faz fica gravado ali.
 Porem, para melhorar a performance eu gostaria de mudar ela.

>>>
>>> Melhorar a performance... do quê?
>>>
>>>
 Talvez, criar uma tabela "feedlog-history" ou ate mesmo "feedlog-2014' e
 mover dados antigos da original para esta? Tornaria maior?

 Enfim.. o que voces aconselhariam?

>>>
>>> Entender o real problema (se é que ele existe) e daí agir depois.
>>> Já vi que teve uma resposta "particionar" mas às vezes não é isso que
>>> vai resolver - depende exclusivamente de que tipo de consultas você faz
>>> sobre ela.
>>>
>>>
 *Aguns dados:*

 Size: 8 GB

 relname  | relkind |  reltuples  | relpages
 ---+-+-+--
   feedlog| r   | 6.60508e+07 |  9974857

>>>
>>> Isso não nos diz muita coisa. Qual o problema de performance que está
>>> experimentando?
>>>
>>> []s
>>> Flavio Gurgel
>>>
>>> ___
>>> 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] Tabela gigante - Melhoria

[Alessandro Lima]

Também tive esse problema com a tabela logged_actions do "audit trigger".
Tinha problemas de performance com tabela de mais de 20GB.
A solução foi particionar(1) a tabela por mês.

(1) http://www.postgresql.org/docs/9.4/static/ddl-partitioning.html


Atenciosamente,

Alessandro Lima
email grandegoia...@gmail.com

Em 14 de dezembro de 2015 02:34, drum.lu...@gmail.com 
escreveu:

> Oi pessoal...
> Eu tenho uma tabela de 8 GB, chamada feedlog.
>
> Nesta tabela eu tenho o historico do usuario dentro do sistema, TUDO o que
> ele faz fica gravado ali.
> Porem, para melhorar a performance eu gostaria de mudar ela.
>
> Talvez, criar uma tabela "feedlog-history" ou ate mesmo "feedlog-2014' e
> mover dados antigos da original para esta? Tornaria maior?
>
> Enfim.. o que voces aconselhariam?
>
> *Aguns dados:*
>
> Size: 8 GB
>
> relname  | relkind |  reltuples  | relpages
> ---+-+-+--
>  feedlog| r   | 6.60508e+07 |  9974857
>
>
>
> ___
> 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] Tabela gigante - Melhoria

[Flavio Henrique Araque Gurgel]

Oi pessoal...
Eu tenho uma tabela de 8 GB, chamada feedlog.

Nesta tabela eu tenho o historico do usuario dentro do sistema, TUDO o
que ele faz fica gravado ali.
Porem, para melhorar a performance eu gostaria de mudar ela.


Melhorar a performance... do quê?



Talvez, criar uma tabela "feedlog-history" ou ate mesmo "feedlog-2014' e
mover dados antigos da original para esta? Tornaria maior?

Enfim.. o que voces aconselhariam?


Entender o real problema (se é que ele existe) e daí agir depois.
Já vi que teve uma resposta "particionar" mas às vezes não é isso que 
vai resolver - depende exclusivamente de que tipo de consultas você faz 
sobre ela.




*Aguns dados:*

Size: 8 GB

relname  | relkind |  reltuples  | relpages
---+-+-+--
  feedlog| r   | 6.60508e+07 |  9974857


Isso não nos diz muita coisa. Qual o problema de performance que está 
experimentando?


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

Re: [pgbr-geral] Autovacuum - Dicas

[Flavio Henrique Araque Gurgel]

Muito obrigado Dickson!
Irei fazer a leitura e, posteriormente, posto os resultados.


Evite o top-posting por favor.
Note que, independente do tamanho de suas tabelas, se elas só tem INSERT 
o autovacuum não fará vacuum, só analyze.


Você postou o comando que mostra isso mas, infelizmente, não postou o 
que interessa - o resultado (o SELECT sobre o pg_stat_all_tables).


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

[pgbr-geral] Coluna data - Migration

[drum.lu...@gmail.com]

countstatus_label_iddeletedlabel5548577417falseNew
appointment2577420falseCompleted,
Advance 2 Weeks155580101trueCompleted, Advance 6 Weeks2577419trueOn Hold39
577418trueResale - New1580101falseCompleted, Advance 6 Weeks80900580105trueTemp
Name235577417trueNew appointment33577420trueCompleted, Advance 2 Weeks
A "status label id 580105" tem 80900 Jobs deletados. Preciso migrar tudo
para a "status label id = 577418" para depois (TALVEZ) deletar a  580105

Porem, estou com dificuldades para criar o script.
Poderiam me dar uma luz por favor?

Obrigado!

Estrutura SQL:

db.public.jobs

DB = nome da Database
Public = Schema
Jobs = Table
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela gigante - Melhoria

[Francisco Junior]

Uma tabela com 8GB não vejo que seja uma tabela "gigante", tenho muitas
bases com tabela de acima de 8GB e 4GB/8GB de RAM e tem funcionado bem,
talvez tenha que ser feito o que o Flavio mencionou, dar uma olhada nas
consultas, talvez um indice já resolva seu problema, verificar se a tabela
não está "inchada" talvez precise de um vacuum full.

Em 14 de dezembro de 2015 10:15, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Oi pessoal...
>> Eu tenho uma tabela de 8 GB, chamada feedlog.
>>
>> Nesta tabela eu tenho o historico do usuario dentro do sistema, TUDO o
>> que ele faz fica gravado ali.
>> Porem, para melhorar a performance eu gostaria de mudar ela.
>>
>
> Melhorar a performance... do quê?
>
>
>> Talvez, criar uma tabela "feedlog-history" ou ate mesmo "feedlog-2014' e
>> mover dados antigos da original para esta? Tornaria maior?
>>
>> Enfim.. o que voces aconselhariam?
>>
>
> Entender o real problema (se é que ele existe) e daí agir depois.
> Já vi que teve uma resposta "particionar" mas às vezes não é isso que vai
> resolver - depende exclusivamente de que tipo de consultas você faz sobre
> ela.
>
>
>> *Aguns dados:*
>>
>> Size: 8 GB
>>
>> relname  | relkind |  reltuples  | relpages
>> ---+-+-+--
>>   feedlog| r   | 6.60508e+07 |  9974857
>>
>
> Isso não nos diz muita coisa. Qual o problema de performance que está
> experimentando?
>
> []s
> Flavio Gurgel
>
> ___
> 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] PgPoolAdmin erro superuser: unknown (Connection error)

[Mauricio Tavares]

Pessoal

Ninguém passou por este problema??

Tem alguém que poderia me ajudar???

Em 9 de dezembro de 2015 18:36, Mauricio Tavares 
escreveu:

> Pessoal, boa tarde
>
> Infelizmente já esgotaram todas as possíveis verificações que conheço, e
> por isto, vou recorrer a ajuda de vocês.
>
>
> Fiz a instalação do pgpool II e pgpooladmin. E estou tendo o seguinte erro
> na página PGPOOL STATUS:
>
> pgpoolAdmin
>
>- This is pgpoolAdmin on
>- For pgpool-II 3.4.
>- Login
>   - login user: postgres
>   - superuser: unknown (Connection error)
>
>
> Aparentemente o erro é do usuário, mas até então, está tudo OK.
>
> Alguém já passou por tal erro???
>
>
> Grato pela atenção.
>
> --
> Mauricio
>



-- 
Mauricio T. Leite
Analista de Sistemas
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela gigante - Melhoria

[drum.lu...@gmail.com]

Ola...

Ops... erro de digitacao galera!
a tabela tem 88 GB (Tamanho total de 115GB) .. desculpe.

* A tabela ja possui indice [1]
** Tamanho real da tabela [1]


Segue link com informacoes:

https://bitbucket.org/snippets/lpossamai/Gdddp

Nao sei como verificar se a tabela tem somente inserts/updates ou deletes.

Obrigado.


2015-12-15 2:02 GMT+13:00 Francisco Junior :

> Uma tabela com 8GB não vejo que seja uma tabela "gigante", tenho muitas
> bases com tabela de acima de 8GB e 4GB/8GB de RAM e tem funcionado bem,
> talvez tenha que ser feito o que o Flavio mencionou, dar uma olhada nas
> consultas, talvez um indice já resolva seu problema, verificar se a tabela
> não está "inchada" talvez precise de um vacuum full.
>
> Em 14 de dezembro de 2015 10:15, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
>> Oi pessoal...
>>> Eu tenho uma tabela de 8 GB, chamada feedlog.
>>>
>>> Nesta tabela eu tenho o historico do usuario dentro do sistema, TUDO o
>>> que ele faz fica gravado ali.
>>> Porem, para melhorar a performance eu gostaria de mudar ela.
>>>
>>
>> Melhorar a performance... do quê?
>>
>>
>>> Talvez, criar uma tabela "feedlog-history" ou ate mesmo "feedlog-2014' e
>>> mover dados antigos da original para esta? Tornaria maior?
>>>
>>> Enfim.. o que voces aconselhariam?
>>>
>>
>> Entender o real problema (se é que ele existe) e daí agir depois.
>> Já vi que teve uma resposta "particionar" mas às vezes não é isso que vai
>> resolver - depende exclusivamente de que tipo de consultas você faz sobre
>> ela.
>>
>>
>>> *Aguns dados:*
>>>
>>> Size: 8 GB
>>>
>>> relname  | relkind |  reltuples  | relpages
>>> ---+-+-+--
>>>   feedlog| r   | 6.60508e+07 |  9974857
>>>
>>
>> Isso não nos diz muita coisa. Qual o problema de performance que está
>> experimentando?
>>
>> []s
>> Flavio Gurgel
>>
>> ___
>> 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] Out of Memory com PG_DUMP

[Cleiton Luiz Domazak]

2015-12-11 19:14 GMT-02:00 Dickson S. Guedes :

> On Mon, Dec 07, 2015 at 10:45:49AM -0200, Cleiton Luiz Domazak wrote:
> > Bom dia pessoal.
> >
> > Estou com um problema ao fazer o dump de um banco que está no RDS, por
> isso
> > tenho que utilizar uma maquina cliente executando o pg_dump, até ai tudo
> > certo.
> >
> > Problema é que de um tempo para cá ao fazer o dump está ocorrendo estouro
> > de memoria dessa maquina cliente.
> >
> > pg_dump: reading rewrite rules
> > pg_dump: reading large objects
> > pg_dump: reading dependency data
> > pg_dump: saving encoding = UTF8
> > pg_dump: saving standard_conforming_strings = on
> > pg_dump: saving database definition
> > Killed
> >
> > A máquina tem 7,5GB de RAM, com 5GB livres, mesmo assim estoura.
> >
> > A base tem 21GB, e possui basicamente largeobjects(é uma aplicação legado
> > que ainda utiliza).
> >
> > A versão do cliente e server do PostgreSQL é 9.4.
> >
> > Alguém tem alguma idéia do que pode estar ocorrendo e o que pode ser
> feito?
>
>
> Você ja tentou fazer o dump de uma tabela por vez, utilizando a flag -t ?
>

Acabei abortando o dump como era feito antes, por fim os engenheiros que
trabalham com esse sistema até preferiram o dump sem os blobs, pois para
fazer o restore era muito demorado, e os blobs são irrelevantes para eles.

Muito obrigado a todos que tentaram ajudar.

>
>
> []s
> Guedes
>
> ___
> 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