Re: [pgbr-geral] Tabela gigante - Melhoria

[Sebastian Webber]

Em 14 de dezembro de 2015 18:17, drum.lu...@gmail.com 
escreveu:

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

Amigo, eu vi o teu link e peguei alguns dados da tabela pra ter idéia de
como ela funciona. Agora te pergunto: o que está acontecendo nela? Você tem
algum problema de lentidão específico? algo que gostarias de melhorar?

Quem sabe começamos por aí?


-- 
Sebastian Webber
http://swebber.me
___
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

[Fábio Telles Rodriguez]

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

> 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ê só não disse ainda qual é o seu dito problema de performance.
> Tem uma consulta? Poderia nos enviar um EXPLAIN ANALYZE?
>
> Sem isso, não tem otimização... sinto muito.
>
>
+1

Realmente... faltam evidências. Tenho tabelas com mais de 800GB de log não
particionadas sem problemas. Não é algo que eu admire... mas o fato é que
não está dando problema. Também temos casos de tabelas de alguns TB mas aí
usam objetos binários.

Enfim, qual o seu problema? É uma consulta lenta? Locks? Manutenção? INSERT
lento? Tem que avaliar corretamente o seu problema. Tamanho por tamanho...
nem é tão grande assim.

-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
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]

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ê só não disse ainda qual é o seu dito problema de performance.
Tem uma consulta? Poderia nos enviar um EXPLAIN ANALYZE?

Sem isso, não tem otimização... sinto muito.

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

[pgbr-geral] Tabela gigante - Melhoria

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

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

Re: [pgbr-geral] Tabela Gigante

[Charly Batista]

Em outra mensagem você colocou Não é simples demais para uma tabela que
terá milhões de registros ???...

O problema não é simplicidade. Na verdade, simplicidade geralmente é a
melhor prática!

O pessoal aqui falou sobre a tal Chave Natural... mas o que vem a ser uma
chave natural??

Durante o processo de modelagem, identificamos atributos ou combinação de
atributos que identificam cada ocorrência (registro) como único. Cada uma
dessas combinações é conhecida como chave candidata. As chaves candidatas
identificam a ocorrência como única, mas precisamos eleger uma delas como
chave primária.

Vamos pegar como exemplo a provável entidade pessoa_fisica abaixo:

create table pessoa_fisica (
id_pessoa
cpf
nome
pai
mae
... )

Dentre os atributos acima, podemos eleger como candidatas os atributos
id_pessoa e cpf.

Cpf, neste caso é a chamada chave natural, visto que a mesma foi
introduzida pelo usuário e diz respeito ao negócio, já id_pessoa é
uma chave artificial, que é controlada pelo banco e não diz respeito ao
negócio, por isso ser artificial. Mas qual a melhor escolha?

Existem várias vantagens e desvantagens associadas à essa escolha. Muitas
vezes, isso levando-se em conta chaves compostas, chaves artificiais
economizam espaço nos índices e nas colunas quando repassadas a FKs e chave
naturais costumam economizar em JOINs (se repassamos a chave natural para
outras tabelas, talvez não precisemos fazer um JOIN) e principalmente no
fato de conter em si uma informação da tupla, ou seja, ela diz exatamente o
que é e a que serve.

Em todo caso, um dos grandes dilemas entre chaves artificiais e chaves
naturais é a volatilidade de tuas regras de negócio. Se você escolhe uma
chave natural e hoje a combinação dela é única, o que fazer com o seu modelo
de dados se amanhã ela não for unica? Seria muito ruim sair remendando o
modelo.

Logo, na minha humilde visão, não incluiria os termos certo e errado em
se utilizar uma chave natural em detrimento de uma chave artificial, mas
sim, ao teu modelo de negócios o que é melhor? Na maioria dos casos, chaves
naturais são a melhor escolha, mas como maioria não significa todos, você
deve rever teu modelo de negócios e claro, dar uma boa estudada nos
conceitos e processos envolvidos em modelagem de dados.


Att,


-- 
Charly Batista
Administrador de Banco de Dados
http://javadevilopers.blogspot.com/
charlyfra...@gmail.com
Linux user #391083

Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então
eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu
tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas
idéias.
  George Bernard Shaw (1856-1950)


Em 28 de outubro de 2010 00:19, Emerson Moretto emore...@gmail.comescreveu:

 260.000 é piada para o PostgreSQL, mesmo para realizar buscas.

 Eu trabalho com um banco com 46 milhões de registros em uma única
 tabela usando PostgreSQL. Não é o banco principal, é de redundância,
 mas ele aguenta muito bem, desde que com índices bem feitos.

 No meu caso:

 - Desnormalizei tudo, usei tudo em uma única tabela e não faço nenhum
 join. (sim, repliquei colunas.. campos vazios... etc)

 - Separei os campos principais de buscas em mais de um campo. E
 coloquei índice para todos esses campos. Ex: nome_completo -
 primeiro_nome, ultimo_nome.

 Então,
 # select * from tabela where primeiro_nome = 'Jose' and ultimo_nome =
 'Silva';
 de certa forma, fica como se fosse um like e ao mesmo tempo com muito
 desempenho.

 - Criei esses índices de nomes usando o próprio valor do campo no
 índice. O PostgreSQL por default faz um hash do valor para melhor uso
 de memória e a comparação.

 Pra fazer isso:
 # create index idx_nome on tabela (nome varchar_pattern_ops);

 Esse varchar_pattern_ops que faz isso acontecer

 Com isso, a consulta:
 # SELECT * FROM tabela WHERE nome LIKE 'JOS%'
 utiliza o índice para fazer o LIKE.

 Dessa forma, a busca será muito rápida (te garanto, no meu caso ficou
 em ~25 ms), mas esse LIKE só vai funcionar para quando a busca iniciar
 com determinado valor. LIKE '%ANA%' ou  LIKE '%ANA' vão funcionar, mas
 fazendo full scan.


 Enfim, tudo que fiz nesse meu case escrevi nesse post:
 http://www.emersonmoretto.com/articles/tag/postgres%209

 * Não sou especialista em PostgreSQL, apenas admiro, defendo e uso
 desde a versão 7.2
 ** Espero ter ajudado e não ter te confundido mais


 att
 Emerson Moretto


 2010/10/27 Listas lis...@arsweb.net.br
 
 
 
  Olá Pessoal,
 
  Sou programador em PHP e utiliso o mysql para fazer meus sistemas,
 
  bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
 resolvi usar o postgresql como banco de dados.
 
  Porém, estou com dúvidas de como fazer a tabela no banco.
 
  A tabela va conter de arrancada 260.000 registros
 
  Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
 cidade, estado, anuncio, etc )
 
  Gostaria de saber como criar esta tabela, a estrutura, tipo
 auto_increment,  ja 

Re: [pgbr-geral] Tabela Gigante

[Roberto Mello]

2010/10/27 Listas lis...@arsweb.net.br:

 Sou programador em PHP e utiliso o mysql para fazer meus sistemas,

 bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
 resolvi usar o postgresql como banco de dados.

 Porém, estou com dúvidas de como fazer a tabela no banco.

 A tabela va conter de arrancada 260.000 registros

 Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
 cidade, estado, anuncio, etc )

 Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment,
 ja que esta tabela vai ser imensa e terá que fazer buscas rápidas.

0) Seu nome é mesmo listas?
1) 260.000 registros é muito pouco
2) Seria bom para sua carreira dar uma estudada na parte teórica de
modelagem de dados

auto_increment do MySQL: use o tipo serial no PostgreSQL
Buscas rápidas: de acordo com suas regras de negócio, modele os dados,
e crie índices adequados. Não posso falar mais do que isso visto que a
pergunta foi tão vaga.

Exemplo:

CREATE TABLE lista_telefonica (
id serial not null primary key,
nome varchar(256) not null,
...
);

CREATE INDEX lista_telefonica_nome_idx ON lista_telefonica (nome);

Há uma infinidade de outras coisas que poderiam ser sugeridas
dependendo das necessidades do sistema.

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

[pgbr-geral] Tabela Gigante

[Listas]

 

Olá Pessoal,

Sou programador em PHP e utiliso o mysql para fazer meus sistemas,

bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
resolvi usar o postgresql como banco de dados.

Porém, estou com dúvidas de como fazer a tabela no banco.

A tabela va conter de arrancada 260.000 registros

Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
cidade, estado, anuncio, etc )

Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment,
ja que esta tabela vai ser imensa e terá que fazer buscas rápidas.


Alguem poderia me ajudar ???

 

 

___
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

[Osvaldo Kussama]

Em 27 de outubro de 2010 19:31, Listas lis...@arsweb.net.br escreveu:


 Olá Pessoal,

 Sou programador em PHP e utiliso o mysql para fazer meus sistemas,

 bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
 resolvi usar o postgresql como banco de dados.

 Porém, estou com dúvidas de como fazer a tabela no banco.

 A tabela va conter de arrancada 260.000 registros

 Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
 cidade, estado, anuncio, etc )

 Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment,
 ja que esta tabela vai ser imensa e terá que fazer buscas rápidas.


 Alguem poderia me ajudar ???



Qual o significado de um campo auto-increment (serial no caso do
PostgreSQL) nesse contexto?
Quem for acessar seu sistema terá que saber qual foi o valor do
auto-increment atribuído ao registro que deseja acessar?
Não seria mais conveniente/eficiente pensar em chaves naturais?

Osvaldo
___
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

[rogeriogrando]

Ola, Seja bem vindo alista.

Para o PostgreSQL 260.000 registros não é tanta coisa assim, acho que você terá 
bons tempos de retorno.
Aconselho você normalizar suas tabela pelo menos até  a (3FN) terceira forma 
normal veja[1]
Já houvi desenvolvedores falando 'Mas vou ter que fazer JOINs...', pois é... 
vai, e crie as regras de relacionamento entre as tabelas foreign key, isso é 
muito importante.
Para o ID você pode criar do tipo SERIAL e defini-la como PRIMARY KEY.[2]
Existem formas interessantes para se criar índices para melhorar a performance, 
veja[3], mas não pare por ai, de mais uma busca na net que você achará formas 
de se criar índices muito interessantes.

[1]http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados
[2]http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL
[3]http://www.postgresql.org/docs/current/static/sql-createindex.html

 Subject: [pgbr-geral] Tabela Gigante

 Olá Pessoal,
 
 Sou programador em PHP e utiliso o mysql para fazer meus sistemas,
 
 bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
 resolvi usar o postgresql como banco de dados.
 
 Porém, estou com dúvidas de como fazer a tabela no banco.
 
 A tabela va conter de arrancada 260.000 registros
 
 Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
 cidade, estado, anuncio, etc )
 
 Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment,
 ja que esta tabela vai ser imensa e terá que fazer buscas rápidas.
 
 
 Alguem poderia me ajudar ???
 

___
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

[Emerson Moretto]

260.000 é piada para o PostgreSQL, mesmo para realizar buscas.

Eu trabalho com um banco com 46 milhões de registros em uma única
tabela usando PostgreSQL. Não é o banco principal, é de redundância,
mas ele aguenta muito bem, desde que com índices bem feitos.

No meu caso:

- Desnormalizei tudo, usei tudo em uma única tabela e não faço nenhum
join. (sim, repliquei colunas.. campos vazios... etc)

- Separei os campos principais de buscas em mais de um campo. E
coloquei índice para todos esses campos. Ex: nome_completo -
primeiro_nome, ultimo_nome.

Então,
# select * from tabela where primeiro_nome = 'Jose' and ultimo_nome = 'Silva';
de certa forma, fica como se fosse um like e ao mesmo tempo com muito
desempenho.

- Criei esses índices de nomes usando o próprio valor do campo no
índice. O PostgreSQL por default faz um hash do valor para melhor uso
de memória e a comparação.

Pra fazer isso:
# create index idx_nome on tabela (nome varchar_pattern_ops);

Esse varchar_pattern_ops que faz isso acontecer

Com isso, a consulta:
# SELECT * FROM tabela WHERE nome LIKE 'JOS%'
utiliza o índice para fazer o LIKE.

Dessa forma, a busca será muito rápida (te garanto, no meu caso ficou
em ~25 ms), mas esse LIKE só vai funcionar para quando a busca iniciar
com determinado valor. LIKE '%ANA%' ou  LIKE '%ANA' vão funcionar, mas
fazendo full scan.


Enfim, tudo que fiz nesse meu case escrevi nesse post:
http://www.emersonmoretto.com/articles/tag/postgres%209

* Não sou especialista em PostgreSQL, apenas admiro, defendo e uso
desde a versão 7.2
** Espero ter ajudado e não ter te confundido mais


att
Emerson Moretto


2010/10/27 Listas lis...@arsweb.net.br



 Olá Pessoal,

 Sou programador em PHP e utiliso o mysql para fazer meus sistemas,

 bom, estou desenvolvendo um sistema on-line de uma lista telefonica e resolvi 
 usar o postgresql como banco de dados.

 Porém, estou com dúvidas de como fazer a tabela no banco.

 A tabela va conter de arrancada 260.000 registros

 Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep, 
 cidade, estado, anuncio, etc )

 Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment,  
 ja que esta tabela vai ser imensa e terá que fazer buscas rápidas.


 Alguem poderia me ajudar ???





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




--
[]s
Emerson G Moretto
emore...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral