from:"Tarcísio Sassara"

2010/1/5 Fabrízio de Royes Mello fabriziome...@gmail.com:

 2010/1/4 Tarcísio Sassara sassara.tarci...@gmail.com

 corte

 Se o aplicativo que faz uso do postgres abre uma conexão e mantem está
 até o fechamento, provavelmente a sessão passa uma boa parte do tempo
 idle e pode ser uma boa configurar o keepalive.

 Se for útil o keepalive, podemos discutir aqui uma boa configuração.


 Vejamos se compreendi bem... dessa forma então eu precisaria modificar
 também a minha aplicação, para verificar se a conexão está ativa no momento
 de alguma transação com o banco de dados Pq se a conexao ficar idle por
 algum tempo (o usuário entra numa tela e sai pra tomar um café), com uma
 configuração diferenciada do keepalive a conexão será desfeita então terei
 de tratar isso na aplicação... certo???

Se a conexão está idle, mas ainda estabelecida, a conexão não será desfeita.
É feito uma checagem. No linux, o padrão é 9 checagens antes de
considerar a conexão como perdida.

A conexão só é desfeita, quando é considerada que foi quebrada. Por
exemplo a máquina foi tirada da tomada.



 --
 Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com

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





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

Re: [pgbr-geral] Eliminar Conexões Perdidas

2010/1/5 Sergio Santi sergio.tra...@gmail.com:
 Pessoal, primeiramente parece-me que as conexões ficam pendentes ou até
 mesmo presas, porque se fossem perdidas o problema não estaria ocorrendo.

 Bem, o keepalive se for possível pode ser um paliativo, mas não me parece
 uma solução definitiva.

 Não vejo problema em ter 70 estações que se conectam ao servidor pela manhã
 e desconectam a noite e que me fazem ter um max_connection=100, por exemplo.

Justamente, isso não é problema. O problema é quando as máquinas são
desligadas abruptamente.

 O que me incomoda é ter um no-break de 12 KWA que não segura a rede durante
 um pico de entrada e que deixa 70 conexões ativas no servidor. Então basta a
 energia voltar que apenas as 30 primeiras máquinas conseguem conexão.

É ai que entra o keepalive_idle.

Não entendi direito, quando você disse a rede, quis dizer as estações
(70 maquinas) certo?
Quando estas maquinas caírem, as conexões serão perdidas.
Para o postgres saber quando estas foram perdidas e que devem ser
eliminadas você deve usar o keepalive.

 Pior ainda é que para resolver definitivamente (ou até o próximo pico de
 energia) é necessário fazer um stop seguido de start no banco.

 Eu sinceramente não consigo conceber o PostgreSQL recusando conexões
 alegando que o número máximo de conexões foi atingido sem se dar conta de
 que os clientes abortaram as conexões.

 Ninguém nunca viu isso antes, na hackers ou outra do gênero?

Sim, existe algumas discussões lá sobre este assunto mas que não
existe uma solução melhor do que essa.

Pelo que entendo, o problema é uma questão de rede e do protocolo TCP.
Quando uma máquina é rancada da tomada, o servidor não é avisado. Só
saberá quando terminar a transação e enviar para o cliente. Por isso
fica a conexão rodando.


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

Re: [pgbr-geral] Eliminar Conexões Perdidas

Aaaah! Tem esse problema!

O keepalive idle só serve para os idles.

Se a sessão estiver fazendo alguma coisa ela não está idle. E continua
até terminar.
Só saberá que deu pau quando terminar a transação e retornar para o
cliente. Nisso vai dar pau e encerrar a conexão.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Eliminar Conexões Perdidas

2010/1/5 Sergio Santi sergio.tra...@gmail.com:
 Além disto tem o fato que mesmo que o servidor devolva alguma coisa para uma
 estação desligada ele registra isto no log, mas se mantém contando aquela
 conexão.

Este ponto eu desconheço. Acredito que quando o servidor falha em
devolver a resposta para o cliente por queda da conexão do lado do
cliente,
está é logada e desfeita.

 Não fiz ainda, mas vou fazer: O banco rodando sozinho fica com umas 4
 conexões. Defino o max_connections para 5. Abro uma conexão e deixo em idle.
 Arranco esta estação da tomada. Tento outra conexão.

 Acho que não vai permitir porque a conexão continua sendo considerada, mas
 vou precisar testar uma hora dessas.

Não vai permitir mesmo. Se você tiver o max_connections = 5 e tiver
feito as 5 conexões e desconectar uma abruptamente
ainda continuará as 5 conexões e se tentar conectar não vai ser possível.
Novamente eu digo. É ai que entra o keepalive_idle. Esta quinta
conexão que você citou que deixaria idle,
se você ter um keepalive_idle baixo, antes mesmo de você ligar a
maquina, a conexão estará livre e poderá fazer a conexão.



 No mesmo caso anterior se abrir uma conexão e solicitar algo demorado, por
 exemplo. Arrancar a estação da tomada. Aguardar o servidor devolver a
 consulta e registrar que o cliente não está ativo e então fazer uma nova
 conexão, acho que ela também será recusada e isto porque até onde alcanço
 apesar de o servidor perceber que o cliente a quem ele tem que entregar a
 informação não está mais lá ele não aceita uma requisição de outra estação.


Como disse, desconheço este fato de o servidor manter a conexão mesmo
de ter verificado que não foi possível entregar a resposta.

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

Re: [pgbr-geral] Eliminar Conexões Perdidas

Devemos notar que se uma query é enviada para o servidor e a conexão é
perdida (cliente tirado da tomada) a query continuará e o servidor não
ficará sabendo da desconexão.
Outros DBAs inconformados com isso, reclamaram na lista psql-geral e
até sugeriram que o postgres verificasse a conexão de tempos em
tempos, claro, essa opção foi descartada pois é ineficiente.
Deveria existir uma maneira de fazer isso sem precisar usar ou desviar
mais recursos. Por problemas no protocolo de rede, isso não existe. Só
é possível saber quando o postgres faz um hit na rede, ou seja, quando
vai devolver o resultado da query.

Se sua aplicação mantém a conexão por muito tempo em idle (pessoal
tomando cafezinho) é possível baixar o keepalive_idle e no caso de
duas premissas ocorrerem, a conexão será liberada.
1ª premissa: A conexão está idle?
2ª premissa: O cliente não respondeu nenhuma das checagens de conexão?
Se estas duas premissas forem verdadeiras, a conexão pode ser desfeita.
Se a conexão estiver apenas idle, ela continuará.

Por isto é seguro baixar o keepalive_idle, pois se sua aplicação fica
muito tempo em idle, mas a conexão ainda existe, a aplicação não será
desconectada.


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

Re: [pgbr-geral] Eliminar Conexões Perdidas

Antes de levar uma chinelada,

2010/1/5 Tarcísio Sassara sassara.tarci...@gmail.com:
 2ª premissa: O cliente não respondeu nenhuma das checagens de conexão?

Esta checagem é feita a nível do kernel, não é o postgres fazendo.

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

Re: [pgbr-geral] Res: Uso de Campos Padrões

2010/1/4 Leonardo Cezar lhce...@gmail.com:
2010/1/2 Tarcísio Sassara sassara.tarci...@gmail.com:
2010/1/2 Leonardo Cezar lhce...@gmail.com:
2010/1/1 Tarcísio Sassara sassara.tarci...@gmail.com:
Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de
chaves naturais compostas.

php: doctrine, propel;
python: SQLAlchemy;
ruby: DataMapper;
java: qualquer framework baseado na porcaria do JPA, por exemplo hibernate;

Abraço!

Opá,
Da lista conheço o SQLAlchemy, o Propel e o Doctrine.

Acho que o Doctrine superou o Propel.
E no site do Doctrine diz: Avoid composite keys

http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#avoid-composite-keys

Se da o suporte mas não recomenda o uso, não é legal.

Bom, o site diz que Doctrine suporta completamente chaves compostas e
ao mesmo tempo diz que devido a um overhead (??) para acessar tais
chaves existe possibilidade de erro (???). No minimo confuso... Deixa
no gelo ...

No projeto que trabalhamos com chaves compostas e Doctrine, ele
funcionou sem nenhum aparente problema.

Acho que o maior problema é com as chaves estrangeiras compostas.
Me parece que esta feature foi adicionada recentemente (relativo ao
roadmap do projeto).
Existem alguns tickets sobre o assunto mas precisaríamos de um pouco
mais de leitura para
entender a ordem cronologia da resolução deste problema para saber se
está tudo OK.

Um dos tickets
http://www.doctrine-project.org/jira/browse/DC-85

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

Re: [pgbr-geral] Geração de dados para testes

2010/1/4 Angelo Augusto Frozza (*UNIPLAC) fro...@uniplac.net:
 Pessoal,

 Que programas podem ser usados para gerar dados para testes?
 Preferencialmente software livre?


Você conhece o pgScript? [1]
É uma linguagem de script para ser usada com o postgres. Nela existe
os geradores.
Na documentação da linguagem [2], você encontra mais informações sobre. [3]

Nos geradores do pgScript da até para gerar dados vindos de uma coluna
de outra tabela.
Útil para as chaves estrangeiras.

E o legal é que o pgAdmin da suporte para esta linguagem. [4]
[ Opá, chegou mensagem nova aqui. ]
Ah, é ezatamente o que o Leonardo citou do pgAdmin.


[1] http://pgscript.projects.postgresql.org/INDEX.html
[2] http://pgscript.projects.postgresql.org/SCRIPT.html
[3] http://pgscript.projects.postgresql.org/SCRIPT.html#id4713134
[4] http://www.pgadmin.org/visualtour.php

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

Re: [pgbr-geral] Geração de dados para testes

 Ah, é **ezatamente**...
O z entrou na frente do x. urgh... Perdão.
-- 
Tarcisio F. Sassara
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Eliminar Conexões Perdidas

Depende.
Se todas ou boa partes dessas sessões desconectadas estavam inativas
(idle) é possível configurar o postgres ou o sistema operacional e não
ter este problema.
No postgresql é feito usando os GUCs que o Jota mencionou.

Mas se as sessões estavam ativas, o postgres só saberá que deu pau
quando tentar enviar a resposta para o cliente.

Isso pode gerar outros problemas alem da impossibilidade de fazer
novas conexões.
Se as sessões estão fazendo consultas pesadas, o postgres continuará
trabalhando desnecessariamente pois
não existe uma forma de recuperar uma conexão e capturar a resposta de
uma consulta feita anteriormente.

Se o aplicativo que faz uso do postgres abre uma conexão e mantem está
até o fechamento, provavelmente a sessão passa uma boa parte do tempo
idle e pode ser uma boa configurar o keepalive.

Se for útil o keepalive, podemos discutir aqui uma boa configuração.


Abraço.

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

Re: [pgbr-geral] Res: Res: Uso de Campos Padrões

2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com:
 2010/1/4 Leonardo Cezar lhce...@gmail.com:
 Considerando apenas o lado do desenvolvedor, utilizar ORMs eh uma
 maravilha eh um sonho, eh produtivo e por ai vai 

 Desde que ele não se obrigue a entender o modelo.

 Minha experiência me diz que somente na normalização, ainda que
 intuitiva, é que se entende um modelo de dados a fundo.  Geralmente, o
 próprio analista fica encantado com o tanto de coisas que não sabia
 sobre a aplicação que especificou.


  o Sou uma fabrica de software que tem varias demandas e uma equipe de
 desenvolvedores com prazos apertados, entao usa essa droga 

 E dane-se o usuário que quer pagar tão pouco para ter tanto em tão
 pouco prazo… a manutenção é problema dele, não da fábrica.

 Nada é de graça.  O triste é que nossa civilização está fixada no curto prazo.


Prefiro um projeto com prazo curto sendo desenvolvido usando o ORM
xyz do que sem nenhum ORM e strings de conexões espalhadas por todo
o código.

Manter uma aplicação desenvolvida por programadores experientes usando
o ORM Open Source xyz é bem mais simples. Imagine ficar dependente
de um programador que criou e usou sua própria maneira mirabolante de
fazer as conexões no banco? Mesmo que esteja tudo documentado, de
início, apenas este saberá como as coisas funcionam.


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

Re: [pgbr-geral] Usando CREATE TABLE com LIKE

Quando os nomes são criados pelo PostgreSQL.
Como em:
 CONSTRAINT tabela_pkey PRIMARY KEY (coluna)
 CONSTRAINT tabela_coluna_key UNIQUE (coluna)

Ele consegue copiar igualmente como está a original. Talvez seja este
o problema.
A chave primaria ele manteve pois terminava com a final _pkey.

Não lembro direito mas acho que na documentação não fala nada.
Talvez não seja possível com nomes diferentes como o índice que você
mostrou de exemplo.

2010/1/4 Emanuel Araújo eac...@gmail.com:
 Pessoal, estou copiando algumas tabelas (varias) de um schema para outro e
 preciso que as novas tabelas herdam toda a estrutura das originais, com isso
 poderia usar alguns métodos, mas preferi fazer usando LIKE, com isso consigo
 copiar toda a estrutura da tabela original para a nova.

 Ao fazer notei que alguns indices foram criados com o nome diferente, ou
 seja, ele não herdou o nome completo do indice, mesmo em schemas diferentes
 ele poderia ter mantido, o que aconteceu com a chave primaria mas não
 ocorreu com os demais.

 Um exemplo seria:

 \d t_cliente
   Table public.t_cliente
  Column | Type  | Modifiers
 +---+
  pkey | integer   | default 0
  codcliente   | text  | not null
  nome | text  |
  fantasia | text  |
  cnpj_cpf | text  |
  inscricao_rg | text  |
  contato  | text  |
  atividade    | text  |
 Indexes:
     t_cliente_pkey PRIMARY KEY, btree (s_codcliente), tablespace
 poli_disk1
     t_cliente_u_pkey_idx01 btree (u_pkey), tablespace poli_disk1

 faz cópia:
 CREATE TABLE backup.t_cliente (LIKE t_cliente INCLUDING DEFAULTS INCLUDING
 INDEXES INCLUDING CONSTRAINTS) ;

 \d backup.t_cliente
   Table backup.t_cliente
  Column | Type  | Modifiers
 +---+
  pkey | integer   | default 0
  codcliente   | text  | not null
  nome | text  |
  fantasia | text  |
  cnpj_cpf | text  |
  inscricao_rg | text  |
  contato  | text  |
  s_atividade    | text  |
 Indexes:
     t_cliente_pkey PRIMARY KEY, btree (s_codcliente), tablespace
 poli_disk1
     t_cliente_u_pkey_key btree (u_pkey), tablespace poli_disk1

 Vejam que ele manteve a chave primaria com o mesmo nome mas o indice ele
 mudou.  Tudo bem que no resultado final eu teria o mesmo indice mas a nível
 de padronização ficaria diferente.

 Existe alguma forma de força a utilização do mesmo dos índices, ou não pode
 ser assim?  Por default o Postgres não faz isso.

 --
 Atenciosamente,

 Emanuel Araújo

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





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

Re: [pgbr-geral] Índices e otimização

2010/1/4 moisespsena moisesps...@gmail.com:

 Então, poq que quando executo o select 'EXPLAIN SELECT * FROM tb2;' demorou
 52ms, mas quando faço sem EXPLAIN, demora 18s ? (veja  a diferença: 52ms
 para 18s);

O Explain lhe da o plano de execução. Ele não faz a query para
explicar o que vai fazer.

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

Re: [pgbr-geral] Res: Res: Uso de Campos Padrões

2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com:
 2010/1/4 Tarcísio Sassara sassara.tarci...@gmail.com:
 Prefiro um projeto com prazo curto sendo desenvolvido usando o ORM
 xyz do que sem nenhum ORM e strings de conexões espalhadas por todo
 o código.

 Uma coisa não tem nada a ver com a outra.
Não exatamente, mas eu já vi isso.


 ORM não significa desenvolvimento mais rápido, dependendo do
 ferramental e do projeto; ausência de ORM não significa configuração
 de conexão espalhada.
Não exatamente, mas eu também já vi isso.


 Rapaz, a gente programava em COBOL e DB2 sem nada desses problemas…
Creio que existiam documentação, boas práticas, acordos entre os programadores.

O problema é trocar um ORM por nada destas boas práticas.
Se você escolher fazer tudo, mas fazer tudo bem feito, legal! É muito melhor.
É que estava no meio da conversa o prazo e tudo bem, não existe uma
relação muito claro.

 creio que tua experiência com programadores, e (ou) teu conhecimento
 de ambientes de programação, devem ter sido restritos a coisas muito
 recentes, e muito ruins.
Exatamente, no caso, experiência com programadores e *professores* ruins.
Eu pensava: Isso não está certo! e continuei estudando.


 Desculpe se parece desprezo, não é.  É espanto.


Não, não pareceu.



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

Re: [pgbr-geral] Res: Res: Res: Uso de Campos Pa drões

2010/1/4 Tiago Adami adam...@gmail.com:
 2010/1/4 Leonardo Cezar lhce...@gmail.com:
 2010/1/4 Tarcísio Sassara sassara.tarci...@gmail.com:

 Prefiro um projeto com prazo curto sendo desenvolvido usando o ORM
 xyz do que sem nenhum ORM e strings de conexões espalhadas por todo
 o código.

 Desisto!

 Voltemos para banco de dados que é a área onde conhecemos o que falamos.


 Sei lá... já que a lista é geral, até seria um pouco pertinente tocar
 nesses assuntos. Clientes (SW) mal-feitos sempre acabam resultando em
 dor de cabeça para os DBAs.

Concordo plenamente.

Quando digo que prefiro o uso de um ORM não digo que só existe ORM.
De forma notável em alguns frameworks, existe uma preocupação com
padrões, testes e documentação que **se** forem seguidos garantem um
desenvolvimento mais organizado.

Não sou um evangelizador destas ferramentas.
Eu sou a favor do que é bem feito. Cansei de ver espaguete e cansei de
ouvir: ... mas funciona!.



2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com:
 2010/1/4 Tiago Adami adam...@gmail.com:
 O uso
 do Caché ou outras alternativas como DB4O considero promissoras

 Promissor de problemas, isso sim...

Concordo.



2010/1/4 MARCIO CASTRO marciomouracas...@yahoo.com.br:
 Tarcísio; muito bem colocado. Concordo plenamente com as suas observações. E
 ainda:

 Imagine ficar dependente de um programador que criou e usou sua própria
 maneira mirabolante de fazer as conexões no banco?

   Tem uma aplicação aquí que é assim. E sem documentação nenhuma. Se tivesse
 sido usado um framework conhecido no desenvolvimento, até que dava para dar
 manutenção, mas do jeito que está, só construindo outra.

E existem muitos outros casos espalhados.

Deveríamos descartar programadores ruins, que não acompanham as
mudanças, que não contribuem com a comunidade mesmo que seja apenas
participando de uma lista de discussão. Alguns nem sabem o que é
isso...
Claro que ninguém é obrigado a nascer sabendo mas é visível aqueles
que querem o saber.

Como deveria ser uma entrevista:
 -- Porque você é programador?
 -- Sei lá, ouvi dizer por ai que da dinheiro.
 -- Muito obrigado, entraremos em contato.

Você pode achar que o mercado é escasso de bons profissionais, mas se
você tem o poder de decisão
prefira esperar ou pagar mais um pouco.



2010/1/4 MARCIO CASTRO marciomouracas...@yahoo.com.br:
   Puxa; achei um cara que também programou em Cobol!!!
   Pensei que eu ainda era o único no mundo, e os demais tivessem morrido de
 velhice!

  corte 
   E lhe digo com muita sinceridade que não tenho nenhuma saudade daqueles
 tempos...

Sinto uma inocente inveja. :-D


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

Re: [pgbr-geral] Res: Uso de Campos Padrões

2010/1/2 Leonardo Cezar lhce...@gmail.com:
 2010/1/1 Tarcísio Sassara sassara.tarci...@gmail.com:
 Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de
 chaves naturais compostas.

 php: doctrine, propel;
 python: SQLAlchemy;
 ruby: DataMapper;
 java: qualquer framework baseado na porcaria do JPA, por exemplo hibernate;

 Abraço!


Opá,
Da lista conheço o SQLAlchemy, o Propel e o Doctrine.

Acho que o Doctrine superou o Propel.
E no site do Doctrine diz: Avoid composite keys

http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#avoid-composite-keys

Se da o suporte mas não recomenda o uso, não é legal.

O ORM provido pelo Django também não faz direito (faz tempo que não
dou uma olhada).


Para novas aplicações criadas isso não é muito problemático. É só
seguir as convenções, mas quando é preciso migrar deve dar uma dor de
cabeça.


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

Re: [pgbr-geral] Re s: Índices e otimização

Moises,
Criar um índice não garante que este vai ser utilizado.
O PostgreSQL usa as estatiscas para saber qual a melhor forma de
buscar os registros no banco.

Por isso a dica de fazer um analize e regerar as estatísticas.
Para garantir que o PostgreSQL fará a melhor escolha.


2010/1/2 moisespsena moisesps...@gmail.com:
 Bem, cliquei com o botão direito em cima da tabela e apareceu uma janela com
 as opçoes: VACUM, ANALYSE, REINDEX. Marquei a opção VACUM e logo abaixo
 novas opções apareceram: FULL, FREEZE e ANALYSE, marquei todas elas e mandei
 executar, em seguida, tive a seguinte saída na aba 'mensagens' localizada na
 parte inferior da janela:

 INFO:  vacuuming public.tb2INFO:  tb2: found 0 removable, 71
 nonremovable row versions in 5834 pages
 DETAIL:  0 dead row versions cannot be removed yet.
 Nonremovable row versions range from 56 to 62 bytes long.
 There were 0 unused item pointers.
 Total free space (including removable row versions) is 52116 bytes.
 0 pages are or will become empty, including 0 at the end of the table.
 1 pages containing 5448 free bytes are potential move destinations.
 CPU 0.12s/0.31u sec elapsed 1.08 sec.INFO:  index tb2_pkey now contains
 71 row versions in 1922 pages
 DETAIL:  0 index pages have been deleted, 0 are currently reusable.
 CPU 0.03s/0.00u sec elapsed 0.03 sec.INFO:  index tb2_idx now contains
 71 row versions in 1922 pages
 DETAIL:  0 index pages have been deleted, 0 are currently reusable.
 CPU 0.01s/0.01u sec elapsed 0.03 sec.INFO:  tb2: moved 0 row versions,
 truncated 5834 to 5834 pages
 DETAIL:  CPU 0.00s/0.00u sec elapsed 0.02 sec.
 INFO:  analyzing public.tb2INFO:  tb2: scanned 3000 of 5834 pages,
 containing 360001 live rows and 0 dead rows; 3000 rows in sample, 700082
 estimated total rowsTempo total de execução da consulta: 1289 ms.

 
 View this message in context: Re: Res: Índices e otimização
 Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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





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

Re: [pgbr-geral] Res: Uso de Campos Padrões

2010/1/2 Andre Fernandes fernandes.an...@gmail.com:
2010/1/2 Tarcísio Sassara sassara.tarci...@gmail.com

2010/1/2 Leonardo Cezar lhce...@gmail.com:
2010/1/1 Tarcísio Sassara sassara.tarci...@gmail.com:
Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de
chaves naturais compostas.

php: doctrine, propel;
python: SQLAlchemy;
ruby: DataMapper;
java: qualquer framework baseado na porcaria do JPA, por exemplo
hibernate;

Abraço!

Opá,
Da lista conheço o SQLAlchemy, o Propel e o Doctrine.

Acho que o Doctrine superou o Propel.
E no site do Doctrine diz: Avoid composite keys

http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#avoid-composite-keys

Se da o suporte mas não recomenda o uso, não é legal.

O ORM provido pelo Django também não faz direito (faz tempo que não
dou uma olhada).

Para novas aplicações criadas isso não é muito problemático. É só
seguir as convenções, mas quando é preciso migrar deve dar uma dor de
cabeça.

Boa tarde,

Honestamente, o uso de ORMs é um assunto deveras polêmico.
Yah! Muito! Existe situações que eles podem ser ignorados ou bem úteis.

Eu, pessoalmente, sou contra. Não considero boa prática ter a estrutura do
banco na aplicação, não vejo razão de transportar a mesma para a aplicação,
ela não precisa saber quais são as tabelas que se usa no banco. A modelagem
do banco de dados pertence ao banco de dados.

Concordo especialmente com a seguinte afirmação: Não considero boa
prática ter a estrutura do banco na aplicação.
Existe um problema muito grande. Um pecado que os desenvolvedores
estão cometendo:
Estão tirando a regras do negócio do banco de dados e colocando-as na aplicação.

E também já vi muitos problemas de desempenho e más implementações quanto a
muitos aspectos referentes ao banco em diversos ORMs de mercado. Incluindo
Doctrine, Propel, Hibernate, entre outros. Mas isso é minha visão pessoal.

Alguns problemas são pelo mal uso mesmo.
Por exemplo: Deixar no modo debug onde é refeito toda hora o mapeamento.

Por outro lado, tenho amigos que são excelentes desenvolvedores (eu sou
analista de dados, mesmo sabendo programar não tenho visão de programador)
que adoram o uso de ORMs. Muitos deles gostam de doctrine para PHP e
Hibernate para Java. Mesmo ao apontar os problemas que encontrei nessas
ferramentas, eles consideram que esses ORMs são ótimas alternativas e ajudam
muito. Mesmo discordando tenho de aceitar a opnião deles pois assim é o
mundo do desenvolvimento de software: há diversas frentes, e quase nunca
apenas uma está correta.

Depende muito, se você iniciar um projeto do zero e seguir as
recomendações das bibliotecas você consegue
um ótimo desempenho. O pior caso é quando você resolve adotar a
ferramenta depois de o modelo estar pronto.
Assim eu concordo. Fica uma droga.

Eu, pessoalmente, considero melhor prática usar visões e procedures para
acessar dados do banco ou mesmo alterá-los, com poucas excessões. O programa
não precisa saber o que está em cada tabela, precisa apenas solicitar que,
por exemplo, insira um novo cliente e mandar os dados dele. E depois precisa
ler os dados do mesmo, não se preocupando se tem 1, 2, 3, ou mais tabelas
que compooem essa informação.
Essa é a minha visão, é como faria. Mas se entrarmos em discussão quanto a
isso a coisa vai longe, é um assunto muito polêmico.

O problema é que em uma aplicação fazemos isto direto. Inserimos e
pesquisamos registros em muitas
sessões (telas). Se não abstrairmos, acabaremos repetindo muito
código. Coisas como abrir e fechar conexão.

E ainda existe o problema dos sistemas que devem ser portáveis.

PS: o hibernate não é baseado no JPA, pelo que me recordo é o contrário.

Ah! Isso é um assunto interessante. Realmente, na prática, o JPA veio
depois do Hibernate mas conceitualmente o Hibernate é baseado no JPA.

JPA é uma especificação.
A JPA foi uma tentativa de especificar uma camada de persistência.
(Não sei dizer se foi uma tentativa bem sucedida)

Hibernate é uma implementação.
O hibernate é o cara realmente. Ele é baseado na especificação JPA.

Quando os caras do Java começaram a criar a JPA usaram como base o Hibernate.

Foi o caso clássico da implementação que veio primeiro da especificação.

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

Re: [pgbr-geral] Res: Res: Uso de Campos Padrões

2010/1/2 MARCIO CASTRO marciomouracas...@yahoo.com.br:
 Mas porquê?


Desculpe-me por querer responder.

Se você criar apenas uma chave primária artificial terá problemas
porque ela (propositadamente) não faz nenhum sentido com o domínio da
Relação e é gerada de forma a não se repetir. A chave artificial é
apenas um dado e com ela você não consegue tirar nenhuma informação ou
conclusão sobre a Entidade armazenada.

Imagine um cenário onde gostaríamos de armazenar as informações de
pessoas (nome e cpf). Podemos inserir pessoas com o mesmo nome mas não
com o mesmo CPF.

Criei uma tabela pessoas tendo como chave primária (artificial) um
coluna que é auto incrementada (cd_pessoa)

create table pessoas (
cd_pessoa serial primary key,
nome character varying not null,
cpf character varying not null
);

Nesta tabela, podemos inserir as tuplas da seguinte maneira:
insert into pessoas (nome, cpf) values ('João', '123.123.123-21');

Mas como a chave primária é a coluna cd_pessoa, poderíamos inserir
novamente a mesma pessoa no banco.
insert into pessoas (nome, cpf) values ('João', '123.123.123-21');

cd_pessoa | nome| cpf
1   | João | 123.123.123-21
2   | João | 123.123.123-21

Note que olhando para a chave primária não obtemos nenhuma informação.

Não usamos a chave natural cpf. Não podemos usá-la para distinguir um registro.
E como o Leandro escreveu:

 (...) criar aplicações sem poder usar chaves naturais é um terror.


Mais à frente escreverei sobre como tratar este problema.
--

Tradicionalmente(?) o mais adequado é encontrar qual a(s)
propriedade(s) da Entidade que queremos armazenar identifica esta como
sendo única. No caso CPF.

create table pessoas (
cpf character varying primary key,
nome character varying not null
);

Assim poderemos inserir pessoas com nomes idênticos mas com cpfs
distintos. Este é o comportamento desejado e aqui estamos usando
adequadamente a chave natural cpf.

insert into pessoas values('123.123.123-21', 'João');
insert into pessoas values('567.567.567-56', 'João');


Se nossa Relação for mais complexa, talvez uma propriedade não
determine a unicidade de uma Entidade armazenada, sendo necessário
usar mais de uma propriedade descrevendo assim uma chave composta.
Dependendo da Relação, a chave ficaria enorme, por exemplo, vendas.
Normalmente criamos uma Relação para as vendas efetuadas e outra
Relação para os itens vendidos.
Na relação que armazenamos as vendas teríamos que usar todas as
propriedades para identificar uma única venda pois não seria possível
identificá-la pelo cpf do vendedor, nem pelo cpf do vendedor mais o
cpf do cliente, nem pelo cpf do vendedor mais o cpf do cliente mais a
data...
Por isso existe um código. Uma chave artificial que encontramos em
toda Nota Fiscal.

--

Eu torno as coisas mais simples.

Criando as Relações usando chaves primárias artificiais e **tratando**
as naturais. (ênfase na palavra tratando)

A mesma Relação do primeiro exemplo.

create table pessoas (
cd_pessoa serial primary key,
nome character varying not null,
cpf character varying NOT NULL UNIQUE
);

Desta maneira, tratando a chave natural, forçando os novos registros
ter um CPF único, não teremos o problema se tivéssemos apenas criado a
chave primária artificial.
Podemos trabalhar como se não existisse a chave artificial.
Poderíamos dropar a coluna cd_pessoa que a Relação ainda manteria a
consistência.

Eu disse tratando as (chaves) naturais no sentido de empregá-las na
lógica, de não esquecer delas, não deixá-las passarem despercebidas.

Fazendo desta forma, qualquer ORM fundo de quintal conseguirá fazer
os joins e de maneira geral identificar unicamente uma tupla.

Para entender o motivo pelo qual estes frameworks/bibliotecas (em
discussão os ORMs) que abstraem o banco de dados preferem uma única
propriedade, precisamos entender mais sobre
a programação orientada a objetos onde normalmente uma classe descreve
as propriedades (e métodos) que um objeto terá, sendo recomendado
especificar uma propriedade que identificará unicamente os objetos
instanciados da mesma classe.
Uma biblioteca ORM trata as tabelas de um banco de dados como sendo
classes e cada registro armazenado como um objeto, portanto, é de se
esperar um único atributo que descreva o registro/objeto.

Assim, os desenvolvedores destas bibliotecas criaram convenções
(padrões) para facilitar o trabalho de todos. Estas convenções são
como acordos entre desenvolvedores e usuários finais.
Cabe a nós decidir se vamos usar ou não estas bibliotecas e seguir
suas convenções. Esta é uma parte de toda controvérsia.

Muitos dos problemas que os desenvolvedores encontram com os ORMs é
tentar migrar o que existe (código e modelo do banco), feito fora das
convenções, principalmente quando o assunto é chaves compostas.

Algum tempo atrás, haviam criticas aos ORMs porque eram muito burros
e tinham comportamentos

Re: [pgbr-geral] Formatar Telefone com to_char

2010-01-01 Por tôpico Tarcísio Sassara

SELECT to_char(telefone,'FM(00)-')

Note o uso do FM no inicio do formato.

Este FM é um modificador e está documentado aqui:

http://www.postgresql.org/docs/8.4/interactive/functions-formatting.html#FUNCTIONS-FORMATTING-NUMERICMOD-TABLE

Na sessão Funções de formatação:
http://www.postgresql.org/docs/8.4/interactive/functions-formatting.html


2010/1/1 GABRIEL DOS SANTOS gabrielworks...@hotmail.com:
 Boa tarde a Todos.

 Alguem poderia me dizer porque a função to_char, quando eu formato um
 telefone do tipo NUMERIC(10). Realizo o seguinte comando:

 SELECT to_char(telefone,'(00)-') AS telefone FROM tbcliente;

 
 Resultado(3)

 ( 62)3323-1078
 ( 62)3323-1112
 ( 62)3323-1434

 o valor retornado acrescenta um espaço entre o primeiro parenteses e o
 primeiro numero?

 Pois quero que retorne sem este espaço, da seguinte forma. Estou utilizando
 a versão 8.4.1.1

 (62)3323-1078



 Grande abraço a todos da Comunidade, Feliz Ano Novo a todos.

 Gabriel dos Santos.

 
 O Novo Windows 7 funciona como você quer. Clique para conhecer!
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral





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

Re: [pgbr-geral] Res: Uso de Campos Padrões

2010-01-01 Por tôpico Tarcísio Sassara

Realmente gosto disto que está ocorrendo aqui. Faz valer o nome deste
lugar: Lista de discussão.
Segue a minha contribuição:

Simplesmente não gosto do estado NULL para o valor de um atributo de
uma Relação.
Usar ou permitir valores nulos para um atributo é uma péssima idéia e
pode causar grandes problemas.
Podemos ignorar completamente este estado e definir para cada atributo
um valor padrão.

O uso das chaves artificiais cresceu muito com a adoção de
Frameworks e seus ORMs.
Inegavelmente o uso destas ferramentas simplificam o desenvolvimento
de sistemas mas afastam os desenvolvedores das teorias que fundaram o
SGBD que hoje utilizamos.
Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de
chaves naturais compostas.
Alias, ORM não são muito legais. Até o David disse: Stop trying to
generate SQL. [1].

Acredito na importância de se estudar os trabalhos dos conhecidos
pesquisadores neste assunto (e que até possuem idéias diferentes) como
Date e Celko.
Não que as idéias destes devessem ser aplicada à risca, pois, cada
caso é um caso.
É importante conhecer as ferramentas que temos a disposição e as
diferentes maneiras com as quais podemos solucionar um problema.
Podemos fixar um prego na parede com uma chave de fenda apesar de ser
muito mais simples com um martelo. E tendo um martelo é possível usar
o cabo ou a cabeça... É o uso da ferramenta, mais a técnica usada de
forma apropriada que faz a diferença e torna o trabalho mais simples e
bem feito.

Se focarmos nas teorias, usaríamos mais as chaves naturais que podemos
encontrar em uma Relação.
Mas existem situações em que precisamos usar as chaves artificiais.
Quando nossa regra de negócio permite inserir um registro antes mesmo
de se ter a chave natural completa.
Por exemplo:
No caso da locadora de vídeos. Se for possível reservar um filme sem
necessariamente especificar para quem, ou seja, apenas queremos
indicar que um filme está reservado para alguém, a chave natural não
estaria completa pois a chave natural da Relação Reserva inclui uma
referência para o cliente que quer o filme e que neste caso não está
preenchida. Pode aqui estar um exemplo de uso do NULL, onde o código
do cliente é indefinido. Mas como escrevi logo acima, podemos esquecer
dos valores nulos e usar valores defaults o que na minha opinião é a
melhor alternativa.
Então, neste exemplo, a Relação Reserva precisaria ter uma chave
artificial identificando uma reserva sem mesmo ter a informação do
cliente que reservou o filme.

Apesar de existir algumas vantagens no uso das chaves naturais como
por exemplo a não necessidade de se criar uma nova coluna para uma
outra chave ou a melhor representação de acordo com o Domínio, na
prática, uso muito as chaves artificiais e as chaves candidatas
naturais se tornam únicas e não nulas.
Tornando as chaves naturais unicas e não nulas, elimina-se o problema
da duplicidade que pode ocorrer usando chaves artificiais sem tratar
as naturais como no exemplo:
cd_pessoa | nome
---
1 | João
2 | João

Chaves artificiais simplificam as queries ad hoc quando é preciso
fazer os joins e torna possível o uso dos ORMs.

Um exemplo de Relação usando uma chave artificial e tratando a natural:

CREATE TABLE pessoas (
cd_pessoa serial PRIMARY KEY,
nome CHARACTER VARYING NOT NULL DEFAULT 'não especificado',
cpf CHARACTER VARYING NOT NULL UNIQUE
);

Quando criamos uma restrição de unicidade, automaticamente criamos um
índice para a propriedade da relação. Isso acontece porque no momento
da inserção de uma nova tupla, o SGBD pesquisa por uma ocorrência do
valor que se quer inserir na Relação. Caso não encontrado, o valor é
inserido. O índice ajuda nesta pesquisa. Este comportamento é ótimo
pois normalmente, também usamos esta propriedade para fazer as buscas
de dentro do nosso sistema.

Referências:
http://books.google.com.br/books?id=y_eVBB5qdwMCprintsec=frontcover#v=onepageq=f=false
http://en.wikipedia.org/wiki/Natural_key

[1]
http://people.planetpostgresql.org/dfetter/index.php?/archives/40-Removing-Much-of-the-Suck-from-ORMs.html

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

Re: [pgbr-geral] dúvida com expressões regulares e a função regexp_matches()

2009-12-19 Por tôpico Tarcísio Sassara

2009/12/19 Osvaldo Kussama osvaldo.kuss...@gmail.com:
 2009/12/18 Tarcísio Sassara sassara.tarci...@gmail.com:
 Estou tentando pegar todas as ocorrências dentro de um padrão e está 
 complicado.

 São palavras limitadas nos dois lados com um hífen -.

 Tentei usar desta forma a função regexp_matches():

 select regexp_matches('-MARIA- -JOAO- -PEDRO-', '-(.*)-')

 Esperando retornar: {MARIA, JOAO, PEDRO}

 Mas estou recebendo {MARIA- -JOAO- -PEDRO}

 Isso porque:
 O primeiro traço da minha expressão está casando com o primeiro traço da 
 string.
 O ultimo traço está casando com o ultimo da string.

 Esperava casar com a primeira ocorrência logo
 após a primeira palavra MARIA e assim ir construindo o vetor com os nomes.



 Da forma abaixo o primeiro e último elemntos do array são strings de
 comprimento zero:

 bdteste=# select regexp_split_to_array('-MARIA- -JOAO- -PEDRO-', E'-( -)?');
  regexp_split_to_array
 --
  {,MARIA,JOAO,PEDRO,}
 (1 registro)

 Uma possível maneira de evitar isso seria eliminar o '-' do início e
 fim antes de tratar:

 bdteste=# select regexp_split_to_array(regexp_replace('-MARIA- -JOAO-
 -PEDRO-','^-(.*)-$',E'\\1'), E'- -');
  regexp_split_to_array
 ---
  {MARIA,JOAO,PEDRO}
 (1 registro)

 Deve existir uma maneira mais elegante.

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


Muito obrigado!

O comportamento que gostaria é exatamente o mesmo do segundo exemplo:
select regexp_split_to_array(regexp_replace('-MARIA- -JOAO-
-PEDRO-','^-(.*)-$',E'\\1'), E'- -');

Estava usando regexp_matches, não funcionaria.

Perdi muito tempo nas palavras e não no delimitador.

Deveria ter estudado a string e encontrado o delimitar que separa as
palavras e usar a função regexp_split_to_array.

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

[pgbr-geral] dúvida com expressões regulares e a função regexp_matches()

2009-12-18 Por tôpico Tarcísio Sassara

Estou tentando pegar todas as ocorrências dentro de um padrão e está complicado.

São palavras limitadas nos dois lados com um hífen -.

Tentei usar desta forma a função regexp_matches():

select regexp_matches('-MARIA- -JOAO- -PEDRO-', '-(.*)-')

Esperando retornar: {MARIA, JOAO, PEDRO}

Mas estou recebendo {MARIA- -JOAO- -PEDRO}

Isso porque:
O primeiro traço da minha expressão está casando com o primeiro traço da string.
O ultimo traço está casando com o ultimo da string.

Esperava casar com a primeira ocorrência logo
após a primeira palavra MARIA e assim ir construindo o vetor com os nomes.

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

Re: [pgbr-geral] Formatar as Respostas de Erro do Banco de Dados

2009-12-18 Por tôpico Tarcísio Sassara

2009/12/18 Gabriel dos Santos focusdesenvolvime...@gmail.com:
 Boa noite a todos,

 Gostaria de saber se existe alguma forma de tratar as menssagens de erro
 quando violam um CONSTRAINT de que foi
 estabelecida em uma tabela. Com por exemplo:

 CONSTRAINT chk_valor_positivo CHECK (valor = 0);

 Pois caso o meu sistema PHP quando for gravar um produto
 com o valor negativo, o banco de dados irá retornar um mensagem
 de erro da seguinte forma:

 ERROR:  new row for relation tbproduto violates check constraint
 chk_valor_positivo

 so que eu gostaria de fazer com que caso a CHECK fosse violada, para
 retornar a seguinte
 mensagem:

 O valor do produto não pode ser menor do que zero.

 Alguem sabe como fazer isto?


 --
 Atenciosamente,
 Gabriel dos Santos
 Diretor Executivo
 Focus Desenvolvimento e Consultoria
 Fone(62) 8481-4662 / 3323-1078

 Nossa Dedicação, Sua Recompensa

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



Não é algo relacionado ao PostgreSQL...

Depende de como estiver trabalhando com o PHP.

Se estiver usando o PDO, poderá usar blocos try-catch para
capturar os erros e tratar como na programação OO de sempre.

Documentação do PHP PDO:
http://php.net/manual/en/book.pdo.php

Outra solução usando o banco é criar uma procedure que insere o
registro e retorna
uma string com o status, tratando qualquer exceção na procedure,
Desta forma nunca retornará um erro para o script PHP.
O problema é ter que criar as funções no banco e manter mais coisas.

Abraço,
Infelizmente não posso lhe ajudar mais.
-- 
Tarcisio F. Sassara
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [Meio-OFF] Casing e Nomenclaturas

2009-12-17 Por tôpico Tarcísio Sassara

2009/12/16 George Silva georger.si...@gmail.com:
 Boa tarde pessoal,

 Em geral qual é o tipo de padrão de digitação e nomenclatura que vocês
 seguem ao trabalhar com tabelas, indíces, chaves, procedures etc? Eu sei que
 no caso do PostgreSQL casing é um pouco irrelevante...mas...

 CamelCase? muitos_underlines_?

 E quanto à nomenclatura dos objetos?
 Tabelas: tbl_foo;
 Chaves: tbl_foo_pk;
 Indices: idx_tbl_foo_campo1?

 É mais uma curiosidade mesmo...


Tirei uns trechos de uma documentação minha:

Nunca uso caixa alta.
Tabelas com substantivos no plural:
usuarios
produtos

E as views como uma extensão das tabelas com nomes descritivos:
usuarios_bloqueados

Colunas com nomes sem prefixo identificador.
Já vi muito colunas com nomes do tipo: str_nome e int_codigo.
Algumas vezes ajuda, principalmente depois de muito tempo sem mexer.
Mas prefiro usar nomes legais: nome, codigo, cpf e data_criacao. Eu sei os tipos
porque sempre uso os mesmos para colunas assim. colunas com nomes,
códigos e cpfs
uso sempre string (character varying).


Restrição do tipo chave primaria com nome singular com o sufixo _pk:
usuario_pk

Check com nome e sufixo _chk:
cpf_valido_chk

Uniques com sufixo _unq:
cpf_unq

Chaves estrangeiras: tabela_coluna_estrangeira_fk:
produto_categoria_id_fk

Indices: tabela_coluna_idx:
produto_titulo_idx


Nas queries sempre coloco as palavras reservadas em maiúsculo:

SELECT  nome, cpf
FROMusuarios
WHERE bloqueado = FALSE
AND  nome ILIKE 'joao%'


O Josh Berkus fala um pouco sobre nomes de tabelas aqui:
http://it.toolbox.com/blogs/database-soup/whats-up-with-the-singular-table-names-33590

É sempre bom documentar. Você pode colocar comentários nos objetos. Veja em:
http://www.postgresql.org/docs/8.4/interactive/sql-comment.html

E com os comentários o autodoc pode gerar uma documentação:
http://www.rbt.ca/autodoc/

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

Re: [pgbr-geral] [Meio-OFF] Casing e Nomenclaturas

2009-12-17 Por tôpico Tarcísio Sassara

2009/12/17 Tiago Adami adam...@gmail.com:
 2009/12/17 Tarcísio Sassara sassara.tarci...@gmail.com:
 (corte)
 Eu sei os tipos
 porque sempre uso os mesmos para colunas assim. colunas com nomes,
 códigos e cpfs
 uso sempre string (character varying).


 Isto é muito importante. Lembro-me sempre de um grande professor que
 certa vez me disse: Se você não vai utilizar o valor da coluna em
 alguma operação matemática, por mais que o tipo seja numérico *hoje*,
 utilize um campo do tipo VARCHAR no banco.

 Assim, se o código mudar e passar a incluir outros tipos de
 caracteres, o impacto é menor - nem tanto na estrutura do banco, mas
 na aplicação que o utiliza.


Sim, podemos dar como exemplo o RG.
Não existe um padrão (único) para validar este campo. (Cada estado ou
orgão emite de uma maneira?).
Não é só numérico. Exemplo: Em Minas Gerais, existem RGs que têm o
prefixo MG-.

Como strings (character varying) podemos usar as operações deste tipo
para formatar a saída da maneira desejada
sem precisar fazer um cast de um tipo numérico.

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

Re: [pgbr-geral] Google Maps e Postgres

2009-12-16 Por tôpico Tarcísio Sassara

2009/12/15 Andre Lopes lopes80an...@gmail.com:
 Bom dia,

 Necessito montar um sistema que dê para fazer o seguinte com o google
 maps...

 Tenho uma base de dados que suporta um sistema de anúncios, na tabela de
 anúncios tenho dois campos onde coloco a Lat e a Lon, isto para cada
 anúncio.

 Precisava de conseguir fazer pesquisas do género, dando um ponto no mapa,
 pesquisar todos os anúncios num raio de 50km.

 Vi também sistemas que utilizam o código postal como ponto inicial no mapa e
 depois dando a indicação do raio, ele devolve os resultados... onde posso
 obter mais informações deste tipo de sistemas?

 Para conseguir fazer isto com o google maps preciso também do PostGIS?


Com o PostGIS você faria isto direto no banco sem precisar do Google
Maps mas você precisaria
ter no banco as informações geográficas da área que você quer consultar.
Trabalhar com o PostGIS é complicado se você não é da área.

Se você tem a latitude e a longitude, com uma linguagem de
programação, você consegue usar
a API do Google Maps e ter bons resultados.

O problema do Maps é que existe um limite de requisições que se você estourar,
podem bloquear sua chave e seu IP. Assim não conseguirá mais usar.
Deve-se ter moderação.

Procure na internet formas de trabalhar com a API do Maps para a
linguagem de sua escolha.

Link da api: http://code.google.com/intl/pt-BR/apis/maps/


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

Re: [pgbr-geral] [OFF-TOPIC] Porque C ?

2009-12-09 Por tôpico Tarcísio Sassara

2009/12/8 Vinicius Santos vinicius.santos.li...@gmail.com:
 Boa noite pessoal,

 Minha dúvida não tem muito a ver necessariamente com PostgreSQL.

 O que eu queria saber é porque a maioria dos grandes projetos são
 feitos sempre em C ?. Kernel Linux, PostgreSQL, Gnome, Oracle(que eu
 saiba). e assim vai...

 Não conheço muito C, porém estou estudando C++, e o autor(Deitel),
 apresenta algumas vantagens em relação ao C, como orientação a objetos,
 vector, etc.

Deitel não é a editora?


 Seria mais questão de gosto escolher entre C, C++, ou até Java para
 desenvolver um SO, ou um SGBD, ou teria alguma razão em específico ?

Não diria que é bem uma questão de gosto. Apesar de C ser muito mais
difícil do que outra linguagem como Java, não seria possível
desenvolver o postgres com a atual performance usando-se Java.
Poderia ser usado C++, porem, por problemas de padronização que
citarei abaixo, é melhor ser o C mesmo.

O C é mais usado por causa das padronizações que são mais estáveis.
Os padrões basicamente definem o comportamento esperado pela linguagem
e as bibliotecas básicas que deve conter. Assim, qualquer um poderá
criar um compilador para qualquer arquitetura seguindo os padrões.

Por exemplo, para compilar o postgres você precisa de um compilador
que implementa as especificações do ANSI C89. [1]
O 89 quer dizer o ano da publicação, sendo assim, o padrão já possui 20 anos.

Se não me engano, a primeira especificação do C++ é de 98 e as
seguintes são muito mais recentes e assim menos em uso ou com
implementações imaturas. [2]

C++ é o C com suporte ao paradigma da programação orientada a objetos.
Todas as características encontradas no C são encontradas no C++.

O problema dos padrões do C++ faz pesar a escolha para o C.
Pode parecer besteira, mas quando você precisar desenvolver algo
grande (como o Postgres) deverá pensar nisso.

C é leve porque é minimalista. Encontramos implementados apenas as
instruções básicas. Como instruções condicionais (if, switch) e loops
(for, do, while), etc...
Até para coisas básicas precisamos importar as bibliotecas necessárias
que contem as
funções que precisamos. Por exemplo: Se você quiser pegar um texto
digitado no teclado precisará incluir a biblioteca stdio.h que possui
as funções para esta tarefa.

C e C++ são compilados de verdade, com instruções entendidas
diretamente pelo processador alvo, não apenas mastigado para uma VM
como no java.

Essas são minhas observações, tenho certeza que você conseguirá
encontrar mais referências para este assunto.

[1] http://en.wikipedia.org/wiki/ANSI_C
[2] http://en.wikipedia.org/wiki/C%2B%2B0x

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

Re: [pgbr-geral] - Versões do PostgreSQL

2009-12-07 Por tôpico Tarcísio Sassara

2009/12/7 Thiago Freitas thiago.frei...@gmail.com:
 Bom dia!

 Onde eu posso encontrar as melhorias da versão 8.3 sobre a 8.1? E da 8.4 em
 relação a 8.3?


Para encontrar todas as mudanças aplicadas desde a primeira versão
você pode consultar o apêndice E da versão 8.4:
http://www.postgresql.org/docs/8.4/interactive/release.html

Então, se você quiser saber o que mudou da versão 8.1 para a 8.4, é só
ir abrindo na ordem.
Como está em ordem descendente, leia de baixo para cima.
São muitas as mudanças desde a 8.1

PS: Falando sério, é uma boa leitura.
Se você _trabalha_ com o Postgres é até divertido. :)


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

Re: [pgbr-geral] resolvido problema com soma de colunas de diferentes tabelas

2009-12-07 Por tôpico Tarcísio Sassara

2009/12/7 Bruno Sales brunosale...@gmail.com:
 eu fuçando aqui ficou assim:



 SELECT meso.the_geom, meso.gid, meso.nome, estabest2007 +
 estabest2007_9_anos as estabest2007, estabfed2007 +
 estabfed2007_9_anos as estabfed2007, estabmun2007 +
 estabmun2007_9_anos as estabmun2007, estabpriv2007 +
 estabpriv2007_9_anos as estabpriv2007
   FROM ( SELECT soc_estab_nfm_2007.mesoregiao,
 sum(soc_estab_nfm_2007.estab_fund_fed) AS estabfed2007,
 sum(soc_estab_nfm_2007.estab_fund_est) AS estabest2007,
 sum(soc_estab_nfm_2007.estab_fund_mun) AS estabmun2007,
 sum(soc_estab_nfm_2007.estab_fund_priv) AS estabpriv2007
           FROM social.soc_estab_nfm_2007
          GROUP BY soc_estab_nfm_2007.mesoregiao) estab2007, ( SELECT
 soc_estab_nfm_2007_9_anos.mesoregiao,
 sum(soc_estab_nfm_2007_9_anos.estab_fund_fed) AS estabfed2007_9_anos,
 sum(soc_estab_nfm_2007_9_anos.estab_fund_est) AS estabest2007_9_anos,
 sum(soc_estab_nfm_2007_9_anos.estab_fund_mun) AS estabmun2007_9_anos,
 sum(soc_estab_nfm_2007_9_anos.estab_fund_priv) AS estabpriv2007_9_anos
           FROM social.soc_estab_nfm_2007_9_anos
          GROUP BY soc_estab_nfm_2007_9_anos.mesoregiao)
 estab2007_9_anos, ( SELECT mesoregioes.the_geom, mesoregioes.gid,
 mesoregioes.nome
           FROM mesoregioes) meso
  WHERE estab2007.mesoregiao::text = estab2007_9_anos.mesoregiao::text
 AND estab2007.mesoregiao::text = meso.nome::text AND
 estab2007_9_anos.mesoregiao = meso.nome::text



Você está usando a versão 8.3?
Na versão 8.4 é possível simplicar com a clausula WITH:
http://www.postgresql.org/docs/8.4/interactive/queries-with.html


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

Re: [pgbr-geral] Erro função lwpotgis.sql

2009-12-07 Por tôpico Tarcísio Sassara

2009/12/8 Vicente Martins geo.marti...@gmail.com:
 JotaComm, as funções foram carregadas no banco de dados sim. Carreguei tanto
 a lwpostgis.sql quanto a spatial_ref_sys.sql, sem apresentar problemas.

 George, vou olhar direitinho o problema da sintaxe, e posto o resultado logo
 após.

 Obrigado pela atenção. Abraço a todos.


No problema que você enviou, o nome da função está errada.

Tente seguir os exemplos desta função (AddGeometryColumn) na
documentação do postgis:
http://postgis.refractions.net/docs/AddGeometryColumn.html



 2009/12/7 George Silva georger.si...@gmail.com

 Os tipos de geometria na função AddGeometryColumn são case-sensitive.

 MULTIPOLYGON  multipolygon.

 Teste também esta sintaxe:

 CREATE TABLE teste2000
 (
        id serial not null,
        constraint tpk PRIMARY KEY(id)
 );

 SELECT * FROM
 AddGeometryColumn('public','teste2000','the_geom',-1,'MULTIPOLYGON',2);

 Uso em geral a forma qualificada para construir tabelas, especificando
 também o nome do schema.

 Att.

 George R. C. Silva

 2009/12/7 JotaComm jota.c...@gmail.com:
  Olá,
 
  2009/12/7 Vicente Martins geo.marti...@gmail.com
 
  Olá a todos.
  Gostaria de pedir ajuda com o erro que segue:
 
  Versoes dos pacotes:
      PostgreSQL 8.3
      Postgis 1.3.3
 
  Erro:
      ERRO:  função addgeometrycomumn(unknown, unknown, integer, unknown,
  integer) não existe
      LINE 1: SELECT AddGeometryComumn ('municipio','municipio_geom',
     ^
      HINT:  Nenhuma função corresponde com o nome e os tipos de
  argumentos
  informados. Você precisa adicionar conversões de    tipo explícitas.
 
  Arquivo:
      Estou tentando importar o arquivo proj_tables_cehapbde.sql criado
  por
  mim, contendo comandos que seguem a sintaxe:
 
      -- Sintaxe:
      --AddGeometryColumn(table_name,
      -- column_name, srid, type,
      -- dimension)
 
      -- Para a tabela municipio;
      SELECT AddGeometryComumn ('municipio','municipio_geom',
  4291, 'multipolygon', 2);
 
  Comando utilizado para importaçao:
   =# \i proj_tables_cehapbde.sql
 
 
  Outras informaçoes:
      Já adicionei os arquivos que contem as funçoes (lwpostgis.sql e
  spatyal_ref_system.sql).
      Já vi que no arquivo lwpostgis.sql tem a funçao AddGeometryColumn,
  e
  já nao sei mais o que fazer.
 
  Você carregou os arquivos lwpostgis.sql e spatyal_ref_system.sql no
  mesmo
  banco que você está executando o seu script? Pelo erro aparentemente a
  função não está carregada no banco que você está importando o seu
  script. É
  interessante você verificar se os arquivos do postgis (lwpostgis.sql e
  spatyal_ref_system.sql) estão no mesmo banco que você está executando o
  seu
  script.
 
 
 
  Desde já agradeço a atençao de vocês.
 
  Abraço a todos.
 
  --
  Vicente Martins
  Analista de Geoinformação - IFPB
  http://geomartinsblog.blogspot.com/
 
  +55 83 88932202
  +55 83 96141969
 
 
 
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s
  --
  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
 
 



 --
 George R. C. Silva

 Desenvolvimento em GIS
 www.sextantegeo2.blogspot.com
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 --
 Vicente Martins
 Analista de Geoinformação - IFPB
 http://geomartinsblog.blogspot.com/

 +55 83 88932202
 +55 83 96141969





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





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

Re: [pgbr-geral] Domain

2009-11-23 Por tôpico Tarcísio Sassara

2009/11/23 Roberto rpdbar...@yahoo.com.br:
 Olá JotaComm,

 obrigado por sua ajuda.

 Estou usando o PostgreSQL 8.4.1 e nele não aparece o banco template1
 como vc mencionou.

 Li em algum lugar que agora é o banco postgres que deve ser usado, isso
 é correto??? Se não como acho o template1 para criar os domains

O template1 ainda existe e deve ser utilizado.
Para ver os bancos do cluster, digite no psql:
\l (um L minúsculo)

Se estiver usando o PgAdmin você deve habilitar uma opção:
File  Options...
Na aba Display, você verá um checkbox: Show System Objects in the Treeview.
Marcando essa opção, você verá o template1.


 Outra coisa tentei criar um domain do tipo serial, mas ele dá erro. Só
 consigo criar na definição de campo de uma tabela. Por que ???

Isso porque o serial não é um tipo básico. Ele é um atalho para se
criar um inteiro
com uma  sequence associado.

Lembre-se. As alterações feitas no template1 só serão copiadas para os
bancos que forem criados depois.
Então, criando domínios no template1 não serão visíveis nos bancos
criados antes da alteração.


 Grato antecipadamente por qualquer ajuda/dica.

 [ ]s,Roberto Barros - BH

 Olá,

 2009/11/17 Roberto rpdbarros em yahoo.com.br 
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

/ Olá pessoal,
 //
 // estou criando meu primeiro banco no PostgreSQL, e gostaria de criar
 // alguns tipos de dados como domain.
 //
 // Onde devo criar esse domains para que todos os bancos possam usar sem eu
 // ter que ficar definindo a cada banco, tem como???
 //
 /
 Cria no banco template1, assim todo o banco que você criar vai possuir o
 domínio, visto que todo o banco criado é derivado do template1 se um
 template não for especificado.

/
 // Também gostaria de saber qual lista de discussão vcs usam para assuntos
 // relacionados ao PostgreSQL.
 //
 /
 A lista é essa mesmo :) Seja bem-vindo a ela.

/
 // Grato antecipadamente.
 //
 // []s,Roberto Barros - BH
 //
 /



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




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

Re: [pgbr-geral] pg_dump para UTF8

2009-11-20 Por tôpico Tarcísio Sassara

2009/11/20 Guilherme Carvalho desenvolvedor@gmail.com:
 Estou precisando fazer um backup de uma tabela que estão num banco em
 sql_ascii para UTF8, e estou usando o comando abaixo.

 ./pg_dump -a -d -C --user=postgres --table=portal.noticia --encoding=UTF8
 portalprefeitura  UTF8.sql

 Depois de abrir o arquivo estou vendo que ainda tem caracteres não
 convertidos, um exemplo seria isto: retorna Ã  Prefeitura de Palmas e
 enfatiza a educaÃ§Ã£o

 A conversão para UTF8 não tem nada haver com troca de caracteres tipo ç para
 ccedil; correto?

Não, não tem nada haver. ccedil; faz parte dos caracteres especiais em HTML.
Normalmente você não precisa usar estes caracteres se estiver usando a
codificação correta.

Para servir páginas na web você deve primeiro decidir qual a
codificação que vai usar e assim usar a mesma
codificação por todo o site.
Exemplo: Usando UTF-8

O banco deve ter o encodign UTF8.
Os scripts do site devem ser salvos com a codificação UTF-8. Verifique
isso no seu editor.
Você especificar no seu html o encoding que está usando dizendo o
charset. No caso:
meta http-equiv=Content-Type content=text/html; charset=utf-8/

Assim você não terá problemas e não precisará usar aqueles caracteres
especiais como o ccedil;

Hoje em dia é altamente recomendado usar o UTF-8. Mas outra
codificação utilizada comumente é o ISO-8859-1
Se estiver usando o ISO-8859-1 o banco deve estar no formato latin1
e o restante das alterações
descritas acima devem ser feitas trocando o UTF-8 por ISO-8859-1.

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

Re: [pgbr-geral] Melhorar Script de Backup

2009-11-20 Por tôpico Tarcísio Sassara

Bom, parece que vocês quiseram automatizar muita coisa e por isso
ficou grande. Tudo bem.
Mas para este script ser distribuído, existe muita coisa ainda para
ser parametrizado.
Por exemplo: Você supõem que o pg_dump esteja no path.

Como existe muitas variáveis para serem definidas, seria melhor um
arquivo com as configurações.


2009/11/20 Dailson Igo Araújo Palheta dailsonara...@prap.mpf.gov.br:
 Olá pessoal. Preciso da ajuda de vocês para propor algumas melhorias
 para um script de backup com identificação de erros e histórico de
 execução. Podem encarar como um teste de conhecimento de Shell
 Script ;-)

 O script possui 456 linhas entre comandos, linhas em branco e
 comentários, por isso, preferi colocar o script em anexo zipado. O
 script de backup encontra-se em rotinas_postgres\script\backup_pg.
 Se acharem melhor, posso colocar o script no corpo da mensagem, mas
 acho que vai ficar muito poluído.

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





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

Re: [pgbr-geral] Melhorar Script de Backup

2009-11-20 Por tôpico Tarcísio Sassara

2009/11/20 Leandro Guimarães Faria Corcete DUTRA leandro.gfc.du...@gmail.com:
 Le vendredi 20 novembre 2009 à 15:32 -0200, Tarcísio Sassara a écrit :
 Por exemplo: Você supõem que o pg_dump esteja no path.

 Isso não é ruim — desde que o procedimento de instalação coloque o
 diretório do binário no caminho de execução do sistema.

Ah! Correto.
O problema é que o script do Dailson não me pede o caminho do
diretório onde está o pg_dump para depois colocar no PATH.

E é mais comum, mais fácil e seguro armazenar em uma variável. Se eu
coloco no PATH, pode haver conflito
com outro executável que eu tenha, pois existe uma precedência entre
os caminhos dentro do PATH, o que eu quero pode não ser executado.



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

Re: [pgbr-geral] Backup via comando SQL

2009-11-18 Por tôpico Tarcísio Sassara

2009/11/18 Tiago Adami adam...@gmail.com:
 2009/11/18 Euler Taveira de Oliveira eu...@timbira.com

 Tiago Adami escreveu:
  Desculpem se este assunto já foi abordado, mas tenho uma vaga lembrança
  de ter lido alguma coisa na internet sobre um script ou função em C para
  fazer backup do banco de dados com a estrutura completa (dados e
  metadados) via comando SQL, sem usar o pg_dump.
 
 Enquanto o pg_dump não for reescrito para ser uma biblioteca (já foi 
 discutido
 no passado), acho pouco provável você ver outro programa que prometa fazer o
 que ele faz.

 Qual a dificuldade de agendar um pg_dump no cron? Se queres fazer via SQL 
 você
 pode criar um função em PL/PerlU, por exemplo, que invoque o pg_dump.


 --
  Euler Taveira de Oliveira
  http://www.timbira.com/


 A minha maior dificuldade é que na maior parte dos clientes que
 atendemos os servidores rodam Microsoft Windows, e nas máquinas em que
 podemos conectar remotamente não temos acesso ao disco - ou ao
 ambiente - do servidor onde está instalado o banco. Nestes casos temos
 que instalar o pgAdmin ou copiar a pasta bin de uma outra instalação
 para fazer o backup por uma estação.

O pg_dump pode fazer o backup de um banco em outro host, basta o pg_dump
ter acesso ao servidor. Se você consegue conectar o PgAdmin em um
servidor remoto,
você conseguirá fazer um dump do banco.
Ou seja: Não precisa se conectar remotamente.
Se você consegue criar uma conexão remota com a maquina do cliente,
teoricamente conseguirá
liberar o acesso para o pg_dump.

A solução que você propõem não é segura.


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

Re: [pgbr-geral] ultimo vacuum full

2009-11-11 Por tôpico Tarcísio Sassara

On Wed, Nov 11, 2009 at 6:07 PM, Marcelo Costa marcelojsco...@gmail.com
 wrote:
 select relname, last_vacuum, last_autovacuum from
 pg_stat_all_tables where schemaname = 'public';

2009/11/11 Edson - Unimake Softwares ed...@unimake.com.br:
 esse select já quebraria uma galho, mas me parece que não funciona no 8.1

Só a partir da versão 8.2 é possível usar o pg_stat_all_tables;

Na documentação do 8.2 você encontra algumas funções que poderá usar:
pg_stat_get_last_vacuum_time(oid)
pg_stat_get_last_autovacuum_time(oid)

Link: 
http://www.postgresql.org/docs/8.2/static/monitoring-stats.html#MONITORING-STATS-FUNCS-TABLE



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

Re: [pgbr-geral] Filtrar registros com determinado cam po sendo único

2009-11-04 Por tôpico Tarcísio Sassara

2009/11/4 Michel Sabchuk miche...@gmail.com:
 Olá Osvaldo,

 SELECT autor, max(data_anuncio) FROM sua_tabela
 GROUP BY autor
 ORDER BY random()
 LIMIT 5;

 Certo, tinha pensado em algo assim, eu encontro os autores com
 anúncios mais recentes numa consulta e na outra trago seus anúncios
 completos. O problema é que os autores podem vir de dois repositórios.

Não é o caso de pegar uma parte de cada tabela e depois fazer um UNION.


 Usando a sugestão do João, acho que o problema não é nem a consulta, é
 a modelagem.
Parece ser sim. Está pensando em refatorar?

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

Re: [pgbr-geral] Sobre palestra do Fernando Ike no PGCon 2009

2009-10-30 Por tôpico Tarcísio Sassara

Isto é valido no Linux.

No Windows os locales não são definidos assim. São nomes diferentes.
Algo como: 'Portuguese, Brazil'.
Ah! Se não me engano, só da pra criar com o locale 'Portuguese,
Brazil' se o windows também estiver configurado.

Então tente ai:
CREATE DATABASE teste
ENCODING = 'UTF8'
LC_COLLATE = 'Portuguese, Brazil'
LC_CTYPE = 'Portuguese, Brazil';



2009/10/30 Rafael Helm - Trevisan Tecnologia rh...@trevisantecnologia.com.br:
 No PGCon 2009, ocorrido na semana passada ... (baita evento) ... o Fernando
 Ike aconselhou que fosse utilizado sempre a codificação UTF-8.

 Inclusive em seu slide, mas precisamente ná pagina 11 tem o script de
 exemplo de criação de uma base de dados.

 Copiei este script e mudei o collate e o ctype para português Brasil mas
 esta ocorrendo erro alguem saberia me informar o motivo? ;-)

 EU preciso criar antes o collate e o ctype?


 Script executado:

 CREATE DATABASE teste WITH ENCODING 'UTF8'
 LC_COLLATE='pt_BR.UTF-8' LC_CTYPE='pt_BR.UTF-8' TEMPLATE template0;

 Erro que ocorre:

 ERRO: invalid locale name pt_BR.UTF-8

 ** Erro **

 ERRO: invalid locale name pt_BR.UTF-8
 SQL state: 42809


 Obs.: O script foi executado em um servidor windows com Postgres 8.4

 Rafael.



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





-- 
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] problema com acentos no UTF8

2009-10-29 Por tôpico Tarcísio Sassara

É possível descobrir se uma palavra possui acentos usando uma expressão regular.

-- Tarcísio possui caracteres diferentes de [a-z 0-9]?
select 'Tarcísio' !~* '^([a-z 0-9])*$'
Retorna verdadeiro. A palavra possui um i com acento.

Comecei com uma função usando o translate como foi passado na lista só
que antes de retornar a string, passo pela ER que verifica o
resultado. Se o retorno for true gero uma exception.
Descubro manualmente o caracter que causou a falha e assim posso
ajustar a função para transformar este novo caracter.

CREATE OR REPLACE FUNCTION
padroniza(palavra text) RETURNS text AS $_$

DECLARE
  _palavra text;
BEGIN
  _palavra = translate(palavra,
'áàâãäéèêëíìïóòôõöúùûüÁÀÂÃÄÉÈÊËÍÌÏÓÒÔÕÖÚÙÛÜçÇ!...@#$%¨*()-_=+´`{[^~}]|¹²³£¢¬ªº°:?,.;/',
'aiiioAIIIOcC');

  IF _palavra !~* '^([a-z 0-9])*$' THEN
RAISE EXCEPTION 'a palavra % possui caracteres estranhos', _palavra;
  END IF;

  RETURN _palavra;
END;
$_$
LANGUAGE 'plpgsql' IMMUTABLE;

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

Re: [pgbr-geral] Sincronizar bancos de dados

2009-10-26 Por tôpico Tarcísio Sassara

2009/10/25 Professador de Idéias professa...@gmail.com:
 Sobre id não há problemas, pois os códigos são únicos por vendedor, filial e
 ano
 o problema é como sincronizar...

Meu email anterior então foi desnecessário. =)

Para sincronizar você pode criar scripts para isso.
stored procedures nos notebooks conectam com o servidor da filial e
enviam os dados.
Depois de criar a stored procedure que envia os dados para o servidor,
você pode criar
um arquivo .bat que usa o psql para chamar a procedure.
Então, como um arquivo .bat você pode rodar a atualização com 1 click.
É possível conectar em um banco de dados por outro usando o dblink. [1]



[1] http://www.postgresql.org/docs/current/static/dblink.html

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

Re: [pgbr-geral] Sincronizar bancos de dados

2009-10-26 Por tôpico Tarcísio Sassara

2009/10/26 Professador de Idéias professa...@gmail.com:
 Tarcísio,
 como são estes stored procedures? os dados são gravados em tabelas normais?

Sim, é copiar das tabelas dos notebooks e inserir nas tabelas da
respectiva filial.

 como é que ele sabe que este dado de ser enviado e o que já foi gravado na
 filial não deve ser mandando?
 explique melhor..

Ai você deve montar um esquema para saber se uma venda é nova.
Por exemplo: Se o vendedor sai as 08:00 da filial no dia 25, todos os
registros inseridos
a partir daquela data serão novos. O vendedor poderá ficar dias fora e
quando voltar, vai inserir
no banco da filial todos os dados a partir da data de sua saída.
Criando uma stored procedure, você
pode passar como parâmetro a data em que deve começa a contar como nova venda.

Atenção!
Se o vendedor pode _*alterar*_ dados e não apenas _*incluir*_ novos, o
processo fica mais
complicado. Por exemplo:
O vendedor ao atender um cliente precisa alterar o telefone de contato dele.
Neste caso, o registro do cliente já existe na filial, então, você não
poderá inserir direto, deverá fazer um update. Mas como vai saber se
pode fazer este update? Talvez, neste tempo em que o vendedor atendia
o cliente, outra pessoa alterou outros dados deste mesmo cliente.

O update é mais problemático.
Pode ser necessário criar uma tabela intermediaria no banco para
armazenar e comparar os registros
para saber se é seguro fazer a atualização.

Sobre a procedure:

O dblink é um contrib do postgresql que lhe permite conectar a outro
banco de dados.
Então a procedure pode fazer o seguinte trabalho usando o dblink:

CREATE FUNCTION sincroniza(data_inicial date) ...
DECLARE
   venda record;
BEGIN

-- conecta no banco da filial
select dblink_connect('filial', 'dbname=filial');

FOR venda IN SELECT *
 FROM vendas
 WHERE data  data_inicial LOOP

  -- para cada venda no notebook insere na filial
  select dblink_exec('filial', 'insert into vendas values ..');

END LOOP;

select dblink_close('filial');

END;


Se tiver duvidas, tente escrever um pouco mais sobre para podermos ajudar.


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

Re: [pgbr-geral] Sincronizar bancos de dados

2009-10-25 Por tôpico Tarcísio Sassara

Você pode usar uma chave do tipo UUID. [1]
Com o UUID você elimina o conflito que pode ocorrer com chaves sequenciais.

Exemplo do problema com chaves sequenciais:
Antes de sair da filial, 2 vendedores atualizam os dados de seus
notebooks de acordo com o servidor na filial.
Digamos que 50 é o código do ultimo pedido registrado na filial,
se 2 vendedores fizerem um pedido em seus respectivos notebooks,
teremos conflitos, os 2 irão gerar um código 51.
Na hora de enviar os pedidos dos notebooks para o servidor, você terá problemas.

Com o UUID, os vendedores poderão gerar pedidos até no mesmo segundo
que o código gerado será diferente.

Então, usando UUID você não terá o problema anteriormente descrito
e pela data do pedido é possível saber se é um novo pedido.

O UUID visto na documentação do postgres é bem grande,
mas você pode criar um esquema de unicidade que atenda o seu problema,
unindo por exemplo:
O (código da filial) + (código vendedor) + (data) + (numero sequencial).
1-1-20081025-1
1-1-20081025-2
1-1-20081025-3
2-5-20081025-23


Será que desta maneira não daria certo?

Abraço

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

[pgbr-geral] versão 8.5alpha2 disponível

2009-10-24 Por tôpico Tarcísio Sassara

Dia 23, enquanto estávamos no PGCon, mais um alpha foi disponibilizado.



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

Re: [pgbr-geral] Dúvida de modelagem de contas de ba ncos

2009-10-13 Por tôpico Tarcísio Sassara

2009/10/13 Bruno Carneiro guimaraescarne...@gmail.com:
 Teoricamente pode sim... nenhuma restrição foi imposta sobre isso. Neste
 caso, o

 ( saldo do dia n+1 ) = ( saldo do dia n ) + SUM(movimentação do dia n+1)

 Se a movimentação do dia n muda, o saldo do dia n muda, e consequentemente o
 saldo do dia n+1 .

A diária é um grupo de movimentações que ocorrem durante um dia. Até ai beleza.
Mas e se você precisar identificar a que horas foi um determinado
saque se você está agrupando todas as movimentações de um dia em um
único registro?
Se eu fizer 10 saques: Vou conseguir saber a que horas e qual foi o
valor de cada um?


-- 
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida de modelagem de contas de ba ncos

2009-10-13 Por tôpico Tarcísio Sassara

Mas cuidado com a idéia dos estornos.
Um estorno não pode ser simplesmente uma operação contraria a outra
com o nome de estorno.
Um estorno possui atributos próprios.


2009/10/13 Jose adriano Alves alves.jadri...@gmail.com:
     2009/10/13 André Ormenese ( Yahoo ) ormen...@yahoo.com.br
     mailto:ormen...@yahoo.com.br

 
 
          Bruno,
          talvez vc não precise alterar lançamentos anteriores. Vc pode
          trabalhar
          como os bancos. Se tiver algum lançamento errado, faça um
          lançamento de
          estorno a débito ou a crédito, conforme a necessidade.
          Assim não precisa ficar recalculando saldos anteriores.
 
          André


 Ótimo.
 Não tinha lido essa mensagem.
 Mas também é excelente idéia, trabalhando igual contabilmente.
 Precisa acertar, faz estorno.
 Concordo com você.




 2009/10/13 André Ormenese ( Yahoo ) ormen...@yahoo.com.br

 Pois é ... a trigger vai recalcular, certo ?!??!
 É esse processamento que eu sugeri não fazer. Apenas para poupar o
 servidor e banco.


 Jose adriano Alves escreveu:
  Com a trigger voce nao vai recalcular NUNCA...
  Quem vai gerencia tudo é a trigger, via insert update ou delete
 
 
  2009/10/13 Jose adriano Alves alves.jadri...@gmail.com
  mailto:alves.jadri...@gmail.com
 
      Não, você não vai calcular todos os dias...
      A trigger vai fazer automaticamente pra vc!!
 
 
      2009/10/13 André Ormenese ( Yahoo ) ormen...@yahoo.com.br
      mailto:ormen...@yahoo.com.br
 
          Bruno,
          talvez vc não precise alterar lançamentos anteriores. Vc pode
          trabalhar
          como os bancos. Se tiver algum lançamento errado, faça um
          lançamento de
          estorno a débito ou a crédito, conforme a necessidade.
          Assim não precisa ficar recalculando saldos anteriores.
 
          André
 
          Bruno Carneiro escreveu:
           Obrigado por essas dicas. Creio que seja esse mesmo o caminho.
          
 
          ___
          pgbr-geral mailing list
          pgbr-geral@listas.postgresql.org.br
          mailto:pgbr-geral@listas.postgresql.org.br
 
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
      --
      
 
      Att.
      José Adriano Alves
      Analista de Sistemas - Móveis Gazin.
      Cel..:  +55 44 8802 3994
      Fone: + 55 44 3663 8000 - 2319
      Mail: alves.jadri...@gazin.com.br
  mailto:alves.jadri...@gazin.com.br
      MSN: jose.adri...@gazin.com.br mailto:jose.adri...@gazin.com.br
 
 
 
      Este e-mail, seu conteúdo e seus anexos estão sujeitos à
      privilégio de comunicação podendo este documento incluir
      informação confidencial e de propriedade restrita da GAZIN e
      apenas pode ser lido por aqueles a qual o mesmo tenha sido
      endereçado. Se você recebeu essa mensagem de e-mail indevidamente,
      por favor avise-nos imediatamente. Quaisquer dados, opiniões ou
      informações expressadas neste e-mail pertencem ao seu remetente e
      não necessariamente coincidem com aquelas da GAZIN, são de
      exclusiva responsabilidade do signatário. Este documento não pode
      ser reproduzido, copiado, distribuído, publicado ou modificado por
      terceiros, sem a prévia autorização por escrito da GAZIN.
 
 
      Antes de imprimir pense em seu compromisso com o Meio Ambiente
 
 
 
 
  --
  
 
  Att.
  José Adriano Alves
  Analista de Sistemas - Móveis Gazin.
  Cel..:  +55 44 8802 3994
  Fone: + 55 44 3663 8000 - 2319
  Mail: alves.jadri...@gazin.com.br mailto:alves.jadri...@gazin.com.br
  MSN: jose.adri...@gazin.com.br mailto:jose.adri...@gazin.com.br
 
 
 
  Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de
  comunicação podendo este documento incluir informação confidencial e
  de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a
  qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de
  e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer
  dados, opiniões ou informações expressadas neste e-mail pertencem ao
  seu remetente e não necessariamente coincidem com aquelas da GAZIN,
  são de exclusiva responsabilidade do signatário. Este documento não
  pode ser reproduzido, copiado, distribuído, publicado ou modificado
  por terceiros, sem a prévia autorização por escrito da GAZIN.
 
 
  Antes de imprimir pense em seu compromisso com o Meio Ambiente
  
 
  ___
  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



 --
 

 Att.
 José Adriano Alves
 Analista de Sistemas - Móveis Gazin.
 Cel..:  +55 44 8802 3994
 Fone: + 55 44

Re: [pgbr-geral] Dúvida de modelagem de contas de ba ncos

2009-10-10 Por tôpico Tarcísio Sassara

Você não pode recalcular um campo com o saldo porque você perderá o
histórico das movimentações.

Você deve criar uma tabela que armazena as movimentações e inserir
todas estas, seja positivas ou negativas.
Fica algo como:
cliente valor data
1 100.00 2009-09-09
1 -50.00 2009-09-09

Quando você fizer quiser pegar o saldo, você faz um soma(SUM) na coluna valor.

select cliente, sum(valor)
from movimentacoes
where cliente = 1
group by 1

Então é só adaptar esta idéia ao seu modelo.

2009/10/10 Bruno Carneiro guimaraescarne...@gmail.com

Quero modelar a movimentação financeira em uma conta.

A conta tem um saldo inicial.

A partir daí haverão várias movimentações.

O saldo inicial + as movimentações vão gerar um novo saldo.

Como eu devo tratar esse saldo de forma eficiente?

1- Guardar somente o saldo inicial e toda vez recalcular o saldo baseado nas
movimentações?
2- Guardar o saldo atual em um campo.

O problema da abordagem número dois é que toda vez que alguém fizer uma nova
movimentação tenho que recalcular, talvez não seja o ideal.

O que me sugerem?
--
View this message in context:
http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25834706.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

--
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida de modelagem de contas de ba ncos

2009-10-10 Por tôpico Tarcísio Sassara

2009/10/10 Bruno Carneiro guimaraescarne...@gmail.com:

Então, minha única dúvida ai seria se no futuro, o usuário modificasse
movimentações do passado, neste caso teria que re-calcular o saldo daquele
dia.

Não entendi o problema de um usuário alterar uma movimentação. Ele
pode fazer isso?

Continuando...

Não acredito que vai ser muito ruim como eu disse pois você não vai
precisar fazer o SUM com todos os
registros de movimentações. Apenas de um cliente de cada vez e:
Um cliente não terá tantas movimentações.

Mas pensando em performance,
Indo pelo seu primeiro e-mail, a alternativa de ter uma coluna com o
saldo atual e depois ir somando e subtraindo com cada movimentação
funciona.
De qualquer forma você precisa de uma tabela movimentações para ter o histórico.
Então, basta ter uma trigger que para cada alteracão na tabela
movimentações, atualize o saldo atual.

Abraço

2009/10/10 Bruno Carneiro guimaraescarne...@gmail.com:

Então, minha única dúvida ai seria se no futuro, o usuário modificasse
movimentações do passado, neste caso teria que re-calcular o saldo daquele
dia.

E se o saldo desse dia muda, todos os saldos dos dias posteriores teriam que
mudar também...

Opções

1- Quando modificar o saldo de um dia, re-calcular os dias posteriores

2- Na tabela de saldo_diário, armazenar somente o saldo DAQUELE DIA, quando
quiser saber o saldo, fazer um sum de todos os dias até aquele.

Creio que a primeira idéia seja melhor, já que não será muito comum
modificar saldos de dias anteriores... afinal uma vez passada a data, não
tem como mais fazer movimentação nela ( teoricamente ), a não ser que tenha
havido algum engano que precise ser corrigido.

Andre Fernandes-2 wrote:

Bom dia,

Uma abordagem possível é guardar o saldo em uma tabela (por exemplo, uma
tabela contendo o saldo diário, no início do dia referente) e então somar
(ou subtrair) apenas as movimentações do dia referido. Muitos bancos
utilizam essa abordagem, pois não se perde histórico nem usa todo o
histórico para cálculos de saldo.

Exemplo:
create table saldo_diario
(numero_conta bigint,
dia_referencia date,
valor numeric(18,3)
);

create table movimentacao
(numero_conta bigint,
tipo_movimentacao bigint, -- supondo ser chave estrangeira, isto é um
exemplo apenas
valor numeric(18,3)
);

cria-se então uma função que calcula o saldo referente ao dia anterior e
grava o valor em saldo_diario. Essa função seria rodada à 00h10 de todo
dia,
por exemplo.

Espero que esteja compreensível a idéia que passei, qualquer dúvida (se
algo
ficou confuso) é só perguntar.

Atenciosamente,
André.

2009/10/10 Bruno Carneiro guimaraescarne...@gmail.com

--
View this message in context:
http://www.nabble.com/D%C3%BAvida-de-modelagem-de-contas-de-bancos-tp25834706p25835162.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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] Dúvida com pg/plsql

2009-10-09 Por tôpico Tarcísio Sassara

2009/10/9 Rudinei Dias rudinei.d...@gmail.com:
  if not found then
raise exception 'Usuário_para não localizado.';
   end if;

está correto.

Para outras queries que não retornam valores você pode forçar um
retorno usando o RETURNING.

Você pode encontrar mais na documentação:
http://www.postgresql.org/docs/8.4/interactive/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW

Lá você encontrará isto:
INSERT ... RETURNING expressions INTO [STRICT] target;


-- 
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] postgresql no mainframe

2009-10-08 Por tôpico Tarcísio Sassara

Olá Carlos,
Você poderia dizer qual é a arquitetura utilizada?
Me desculpa, não sei nada sobre mainframes.
É apenas uma curiosidade minha saber qual é a arquitetura (pelo menos
uma das muitas).

Abraço

2009/10/7 Carlos Azevedo cazeved...@gmail.com:

  Caros da comunidade,

  Saberiam se é possível usar o postgresql em ambiente mainframe ?

  aguardo.

  obrigado.

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





-- 
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] postgresql no mainframe

2009-10-08 Por tôpico Tarcísio Sassara

2009/10/8 Carlos Azevedo cazeved...@gmail.com:
 A idéia é rodar em  IBM websphere 6.1  com  sistema operacional Z/OS

Legal. :-)

Mas não sei.
Acho que um dos problemas deve ser os scripts de
configuração, compilação e instalação que fazem uso do make.

Boa sorte!


-- 
Tarcisio F. Sassara
Nzb ryn. Ibpê fnor dhrz? Fvz é ryn! Gnzvelf.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Aumentar Número de Indices por Tabe la

2009-10-02 Por tôpico Tarcísio Sassara

2009/10/2 Mozart Hasse mozart.ha...@usa.net:
 Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão
 simplório?!

1 + 32 + 1.

1 para escrever no log.
32 outros arquivos sendo um para cada índice.
1 para a tabela.

--
Mozart, a única *coisa estranha* que *eu* vejo é a necessidade de usar
44 índices.
Provavelmente você está criando um para cada coluna.

Você mesmo disse:
 ... eu quase sempre uso todos os 89 campos ...

Então crie 1 índice contendo todas as colunas que fazem referência às dimensões.
Mesmo que você faça uma consulta que não utilize estas colunas no filtro,
a consulta ainda poderá usar o índice parcialmente.

Não crie também índices malucos como exemplo:
1 índice para cd_cliente, outro para cd_produto e outro para as duas
colunas: cd_cliente e cd_produto.
Apenas crie 1 índice para as 2 colunas.

Entende?

Novamente eu recomendo para você o livro:
http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704

--
O amigo Andre pouco tempo atrás já falou sobre os propósitos desta
lista e de nossa boa vontade.
Gostaria de acrescentar apenas o seguinte:
No processo de aprendizado devemos quebrar nossos paradigmas. Resetar
nossos conceitos.
Entender o que a outra pessoa está querendo dizer para depois apelar
para o que já sabemos e
escolher por em pratica o novo conhecimento adquirido.
Quando comecei a estudar os conceitos de um Data Warehouse, fiquei
abismado com a idéia de
quebrar totalmente as formas normais, e criar um esquema em
estrela[1]. Depois eu entendi o porque. Se
tivesse sido contrario e rejeitado a informação nunca conseguiria
construir um Warehouse decente.

[1] http://en.wikipedia.org/wiki/Star_schema


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

Re: [pgbr-geral] DataWarehouse

2009/9/29 Alcione Benacchio benacc...@gmail.com:

 Descobri um tal de Bizgres, que não consegui fazer download ainda e também
 não sei se é bom.

Este Bizgres foi patrocinado pela Greenplum[1]

A versão comercial é chamada de Greenplum Database e está na versão 3.3[2]
Na página da versão comercial existe um link para se registrar e assim
poder fazer o download dos produtos.

Após se registrar e fazer o login, é só ir na área de downloads e lá
terá o Bizgres na ultima versão 0.9.


[1] http://www.greenplum.com/
[2] http://www.greenplum.com/products/greenplum-database/


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

Re: [pgbr-geral] Aumentar Número de Indices por Tabe la

2009/9/30 Fernando Maia maia...@gmail.com:
 Eu sei dessa alteração no pg_config_manual.h, mas não sei se fiz certo... o
 que eu fiz foi o seguinte: baixei o postgres.tar.gz alterei o
 pg_config_manual.h e compilei e instalei o postgres... mas não resolveu meu
 problema.

Então colega, se você baixo o Postgres, alterou o arquivo pg_config_manual.h
depois configurou, compilou, instalou e criou o cluster com initdb,
não deveria dar problemas.

Eu recomendo dar uma revisada nos passos que você seguiu.

Se você já tiver feito as operações acima sem antes ter alterado o pg_config,
você vai precisar configurar, compilar, instalar e criar um novo
cluster com o initdb.

Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo:

drop table if exists teste;
create table teste (
 cola integer not null, colb integer not null, colc integer not null,
cold integer not null,
 cole integer not null, colf integer not null, colg integer not null,
colh integer not null,
 coli integer not null, colj integer not null, colk integer not null,
coll integer not null,
 colm integer not null, coln integer not null, colo integer not null,
colp integer not null,
 colq integer not null, colr integer not null, cols integer not null,
colt integer not null,
 colu integer not null, colv integer not null, colw integer not null,
colx integer not null,
 coly integer not null, colz integer not null, cola2 integer not null,
colb2 integer not null,
 colc2 integer not null, cold2 integer not null, cole2 integer not
null, colf2 integer not null,
 colg2 integer not null, colh2 integer not null, coli2 integer not
null, colj2 integer not null,
 colk2 integer not null, coll2 integer not null, colm2 integer not
null, coln2 integer not null,
 colo2 integer not null, colp2 integer not null, colq2 integer not
null, colr2 integer not null,
 cols2 integer not null, colt2 integer not null, colu2 integer not
null, colv2 integer not null,
 colw2 integer not null, colx2 integer not null, coly2 integer not
null, colz2 integer not null);

create index teste_idx on teste using btree (
 cola, colb, colc, cold, cole, colf, colg, colh, coli, colj, colk,
coll, colm, coln, colo, colp,
 colq, colr, cols, colt, colu, colv, colw, colx, coly, colz, cola2,
colb2, colc2, cold2, cole2,
 colf2, colg2, colh2, coli2, colj2, colk2, coll2, colm2, coln2);

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

Re: [pgbr-geral] Aumentar Número de Indices por Tabe la

2009/9/30 Euler Taveira de Oliveira eu...@timbira.com:
 Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela.

1: Foi mals. Acho que não entendi/li direito. =D

2: Nunca vi isso.
Em um DW eu coloco na tabela fato as chaves estrangeiras de cada
dimensão e coloco
apenas um índice contendo todas estas chaves.

E de qualquer maneira, a constante INDEX_MAX_KEYS encontrada no
pg_config_manual se refere a quantidade
maxíma de colunas em um índice e não a quantidade de índices por tabela.


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

Re: [pgbr-geral] Aumentar Número de Indices por Tabe la

2009/9/30 Fernando Maia maia...@gmail.com:
 exato... na realidade preciso fazer isso:

 create table fato(
 coluna01 integer,
 coluna02  integer,
 coluna03  integer,
 .
 .
 .
 coluna50  integer,
 PRIMARY KEY(coluna01,coluna02,coluna03...coluna50) );

Opá, opá.
Então, da uma olhada lá no arquivo pg_config_manual.
O único detalhe sobre performance é colocar um número múltiplo de 32.
Talvez 64 resolva, não?
E siga tudo do começo: configura, compila, instala e cria o cluster com initdb.



Abraço.

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

Re: [pgbr-geral] Aumentar Número de Indices por Tabe la

2009/10/1 Fernando Maia maia...@gmail.com:
 esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a
 fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico
 da tabela fato a criação de todas as dimensões como primary key.

Mas Fernando, está correto. Estas colunas identificam um registro na
tabela fato.

Explicando um pouco melhor:
O banco de dados de produção, ou seja, aquele que é utilizado pela
aplicação do cliente
deve ser separado do banco que será o Data Warehouse.

Não da para usar um mesmo modelo para as duas coisas: Produção e Análise.

Primeiro vem o banco produção onde você vai criar todas as tabelas
com as chaves primarias e estrangeiras,
índices e se possível, seguindo as formas normais.

Depois vem o banco warehouse que deve conter uma estrutura
especifica para este problema.
Uma dica para o warehouse que tem muitas dimensões é ver se você não
está colocando 2 vezes a mesma dimensão.
Ex: Uma coluna apontando para uma dimensão ano e outra apontando
para mês, quando o correto seria uma única referência para
uma dimensão chamada data.

Depois você deve criar um script que transforma e envia os dados do
banco produção para o banco warehouse.

Claro, se você estiver carregando os dados vindos de um arquivo de
texto, você não terá um banco em produção.
Somente terá o warehouse.


Eu lhe recomendo um livro muito bom:
The Data Warehouse Toolkit (Ralph Kimball)
http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704

Abraço!

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

Re: [pgbr-geral] Res: Res: Res: Res: Memory (heap)

2009-09-25 Por tôpico Tarcísio Sassara

   Puxa; você escreveu sobre um outro problema que estou tendo aquí:
 determinados cálculos são feitos na aplicação (Java), e estão demorando dias
 - isto mesmo, dias - para finalizar.
   Parte disso é devido ao overhead do servidor de aplicação com o servidor
 do banco. Já realizamos inclusive um teste com ambos na mesma máquina, e a
 performance melhorou de forma significativa, mas ainda está muito lenta.
   Achei então que, se eu portasse a mesma para PL/pgSQL, a performance seria
 superior, o que não se comprovou.

Bom Márcio, eu recomendaria fazer um estudo e tentar mudar alguns processos.
Com base no trabalho atual e com base no conhecimento obtido será
muito mais fácil encontrar uma solução melhor.

Onde trabalho existe 1 banco muito mal desenhado, fruto do trabalho de
uma galera despreparada.
Já falei para os responsáveis deste que é preciso mudar pois se não,
as queries que hoje demoram horas, começaram a durar dias.
A mudança é inevitável. Não da para contornar o problema investindo em
hardware mas o pessoal é relutante e vejo o
problema como uma bomba prestes a explodir.

Com o banco que trabalho hoje tive que refatorar algumas coisas, ficou
muito bom. Funciona muito bem.
Tem coisas que não tem solução e precisam mudar. É uma evolução.
Todo trabalho gasto pra melhorar é recompensado depois.


   No mundo Oracle, é comum deixar muita coisa por conta do PL/SQL,
 justamente devido à performance e para evitar o overhead da rede.

Ah é verdade! Eu estou me graduando, fazendo Sistemas de Informação. O
nosso professor deixou bem claro como a galera costuma fazer com o
Oracle.
Eu já lí muito sobre este assunto e existem muitos prós e contras que
equilibram a decisão de onde ficará as regras de negócio.
Sou muito flexível quanto a isso e não vejo problema em colocar a
lógica no banco desde que seja bem feito e resolva a situação.
Particularmente no banco só coloco os dados e as constraints como as
chaves estrangeiras, unicidades e checks que impedem a degradação do
banco como duplicidades...
Uso procedures para unir comandos que uso constantemente e deixo a
lógica junto da aplicação.

Faço desta maneira porque foi assim que aprendi desde os meus tempos
com PHP e MySQL e porque acho que separando a
lógica do banco de dados, posso separar as duas coisas em maquinas
distintas ganhando com isso.
Meu professor disse que é bem simples. Basta gastar muito com uma
única boa máquina ou Grid.

Mas provavelmente colocaria tudo no banco se o Oracle aparecesse
primeiro pra mim.
Ai vira questão de gosto.


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

Re: [pgbr-geral] Res: Res: Res: Res: Res: Memory (heap)

2009-09-25 Por tôpico Tarcísio Sassara

2009/9/25 MARCIO CASTRO marciomouracas...@yahoo.com.br:
 e vou ter de aprender o DB2 para breve. Trabalho
 para uma empresa que desenvolve um ERP que deve rodar em qualquer banco.
 Quem escolhe é o cliente;

Sério. Comparado com você, tenho zero de experiência com o Oracle e
outros SGBDs.

Minha duvida é:
Como fazer um ERP rodar em diferentes bancos se atualmente roda em
Oracle e dependente da pl/sql?
Você falou do DB2. Existe maneira de portar as rotinas em pl/sql do
Oracle para o que seja feito no DB2?
Como você faria se eu como cliente escolhesse o DB2 ou SQL Server?

Isso me ajudaria entender algumas coisas.

Valeu.


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

Re: [pgbr-geral] init.d inicializando o postgres automaticamente

Pronto, pronto.
Segui os passos contidos no próprio arquivo do contrib.

Mas lendo o arquivo por inteiro, abaixo da linha STOP EDITING HERE o
script faz uma coisa estranha.
Eu achava que era sempre correto inicializar e parar o postgres com o
pg_ctl. Porem:

# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value and can cause the postmaster to misrecognize a stale
# lock file)
DAEMON=$prefix/bin/postmaster

Não sabia deste problema mas encontrei uma thread interessante na lista, uma
boa discussão entre o Tom Lane, Josh Berkus e outros.
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01390.php

De qualquer maneira, devemos (se for o caso) utilizar o start-script do
contrib mesmo.



2009/9/23 Joao Cosme de Oliveira Junior joao.co...@serpro.gov.br

 vai no contrib start-scripts la no source e copia pro seu init.d
 modificando o seu pgdata  no arquivo


 Em 23/09/2009 às 21:14 horas, pgbr-ge...@listas.postgresql.org.brescreveu:

  Tarcísio Sassara escreveu:

 Olá pessoal.
  Motivação:
 Uma das coisas que já resolvi é não utilizar o pacote de instalação do
 debian para a próxima aplicação.
 Minha preocupação é a de sempre manter o banco rodando sempre na ultima
 versão corrente.
 Fiz alguns testes para a migração da minha base da versão 8.3 para a 8.4
 rodando a
 versão antiga simultâneamente mudando a porta de comunicação e tudo ocorreu
 muito bem.

  O problema:
  Minha duvida é como configurar o serviço para inicializar e parar
 automaticamente com o SO usando o
 init.d que é um dos padrões do debian para esta tarefa. Gostaria de chamar
 o pg_ctl start e stop no momento correto.

  Tentei aprender algo com a maneira que o pacote do postgres no debian faz
 mas é meio doido.

  Se alguém puder me ajudar, ou tiver um material legal sobre o assunto vou
 agradecer bastante.
 Dei uma pesquisada sobre o init.d mas de qualquer maneira, gostaria de mais
 informações relacionadas ao postgres.

  Valeu!

 --
 Tarcisio F. Sassara

 --

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



 Boa noite Tarcísio.

 Há algum tempo tive o mesmo problema, abaixo uma descrição rápida da
 solução que encontrei:


 Iniciando o servidor de banco de dados PostgreSQL no boot do Debian
 Script para postgres como serviço e iniciar tal serviço no boot do Debian

 #!/bin/sh
 # pg_script
 # Controla start / stop do Postgresql

 case $1 in
 start) echo -n Iniciando servico do PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl start -D
 /usr/local/pgsql/data  logfile 21
 ;;
 stop) echo -n Parando serviço do PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl stop -D
 /usr/local/pgsql/data  logfile 21
 ;;
 restart) echo -n Reiniciando serviço PostgreSQL;
 /bin/su - postgres -c /usr/local/pgsql/bin/pg_ctl restart -D
 /usr/local/pgsql/data  logfile 21
 ;;
 esac
 exit 0

 Link simbólico para executar o script na runlevel 2

 cd /etc/rc2.d
 ln -s ../init.d/pg_script S50pg_script
 telinit rc2.d

 Saída do comando 'netstat -tuapen'

 Conexões Internet Ativas (servidores e estabelecidas)
 Proto Recv-Q Send-Q Endereço Local  Endereço Remoto
 Estado  User   Inode   PID/Program name
 tcp0  0 0.0.0.0:111 0.0.0.0:*
 OUÇA   0  42251502/portmap
 tcp0  0 0.0.0.0:34256   0.0.0.0:*
 OUÇA   0  42951513/rpc.statd
 tcp0  0 0.0.0.0:113 0.0.0.0:*
 OUÇA   0  53772225/inetd
 tcp0  0 0.0.0.0:22  0.0.0.0:*
 OUÇA   0  50081907/sshd
 tcp0  0 127.0.0.1:631   0.0.0.0:*
 OUÇA   0  50741934/cupsd
 *tcp0  0 127.0.0.1:5432  0.0.0.0:*
 OUÇA   1001   64772380/postgres  *
 tcp0  0 127.0.0.1:250.0.0.0:*
 OUÇA   0  52742201/exim4
 tcp0  0 127.0.0.1:6010  0.0.0.0:*
 OUÇA   1000   81202721/0
 tcp0160 192.168.0.244:2210.200.110.54:50489
 ESTABELECIDA 0  80822717/sshd: leandro
 tcp6   0  0 :::22   :::*
 OUÇA   0  50061907/sshd
 tcp6   0  0 ::1:631 :::*
 OUÇA   0  50751934/cupsd
 *tcp6   0  0 ::1:5432:::*
 OUÇA   1001   64782380/postgres   *
 tcp6   0  0 ::1:6010:::*
 OUÇA   1000   81212721/0
 udp0  0 0.0.0.0:68  0.0.0.0:*
 0  61162336/dhclient
 udp0  0 0.0.0.0:50629   0.0.0.0:*
 10549791895/avahi-daemon:
 udp0  0 0.0.0.0:841 0.0.0.0:*
 0  4281

Re: [pgbr-geral] Memory (heap)

Bom dia pra todos.

Acompanhando as mensagens de perto, achei o assunto interessante e resolvi
brincar um pouco.
Mas antes, minha opinião:

Se só quero usar o SGBD para armazenar dados temporários com direito a
acesso muito rápido, talvez seja melhor usar outra abordagem que não
empregue o postgres.
Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso
para armazenar algo descartável e que é mais importante um acesso rápido,
eu, de primeira,
pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai ir
para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal o
resultado para esta abordagem.

Fui para a maquina virtual fazer alguns benchmarks bem por cima.

1º teste: instalação padrão.
2º teste: instalação com todo o cluster e binários em um fs temporário.
3º teste: instalação padrão com um tablespace temporário.

Comandos do pgbench utilizados

# inicializa as tabelas usadas pelo pgbench com um scale factor igual a 10
no banco de dados postgres
pgbench -i -s 10 postgres

# roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada
uma destas.
pgbench -c 10 -t 1000 postgres


1º teste: Instalação padrão. Resultado:

 tps = 477.656061 (including connections establishing)
 tps = 478.578011 (excluding connections establishing)
---

2º teste: Instalação com todo o cluster e binarios em um fs temporario:

montei um tmpfs seguindo o comando de um dos links fornecidos pelo Fabrízio.
Aumentei o tamanho do fs para conseguir rodar o pgbench:

$ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700 tmpfs
/home/tarcisio/tmpfs
configurei e instalei o postgres junto com o contrib tudo ai dentro.
Rodei o pgbench:

 tps = 823.146755 (including connections establishing)
 tps = 825.540711 (excluding connections establishing)

Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster
inteiro junto com os binários do postgres dentro de um fs temporário.
Se o que quero é algo bem simples e minha aplicação não utilizará o postgres
pra nada alem disso, prefiro estudar outras ferramentas.

---

3º teste: Instalação padrão com um tablespace temporário.

Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
Montei de novo com tudo limpo e criei o tablespace:
=# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do
tablespace
Disso: create table tabela_aqui
Fiz isso: create table tabela_aqui TABLESPACE tmpfs
E disso: alter table pgbench_*** add primary key (bid)
Fiz isso: alter table pgbench_*** add primary key (bid) USING INDEX
TABLESPACE tmpfs
Compilei o pgbench de novo e rodei:

 tps = 453.644599 (including connections establishing)
 tps = 454.687999 (excluding connections establishing)

Foi pior que a instalação padrão! Ou seja, talvez não seja uma boa opção.
(ou benchmark mau feito)
Se já uso o postgres no cotidiano da minha aplicação, não tentaria inventar
moda.
Criaria a tabela normalmente e ficaria agradecido pela velocidade que fosse.
(isso é uma meia-verdade)

O postgres não é lento para consultas em uma única tabela pequena como a que
pensaríamos em colocar na memória.
A coisa só começa a ficar feia com consultas complexas envolvendo joins e
cálculos. O que vale para outros SGBDS.



2009/9/24 Fabrízio de Royes Mello fabriziome...@gmail.com



 2009/9/23 Euler Taveira de Oliveira eu...@timbira.com

 Dois comentários: (i) se você preza pelos seus dados *não* faça isso a não
 ser
 que os mesmos sejam dados de sessão e (ii) mesmo que você crie uma
 tablespace
 e coloque a sua tabela lá, os dados vão precisar ser escritos no WAL então
 _nem_ tudo vai ser escrito em memória.


 Com certeza, mas em se tratando de dados voláteis não teriamos problemas
 não é mesmo... e no caso do WAL o artigo que indiquei consta um comentário
 do Sr. Pavel Stehule que fala justamente sobre a escrita no WAL então seria
 interessante ter o cluster inteiro na ramfs para ter tudo em memória...



 Quanto a dúvida do OP, o PostgreSQL *não* possui um equivalente ao
 _engine_
 memory. Apesar disso, se essa tabela é utilizada com certa frequência e
 você
 possui uma configuração adequada de _shared buffers_, com certeza, esta
 tabela
 estará na memória.


 No comentário ele também fala que o mais correto seria ajustar o valor do
 shared buffers... mas tendo um valor adequado nesse parâmetro mesmo assim
 teremos I/O do WAL certo? Então se a necessidade é escrever dados em memória
 em função do desempenho de I/O então o cluster inteiro na RAM seria
 inevitável... e pra manter isso somente com dados voláteis mesmo... (que
 baita *gambiarra* isso me parece)


 O amigo Everson poderia dar mais detalhes da sua real necessidade, porque
 daqui a pouco não é com o PostgreSQL que ele vai encontrar a solução. Há
 algum tempo li o artigo Database Overkill do Sr.

Re: [pgbr-geral] Res: Memory (heap)

Ah, então Márcio, eu cheguei a acompanhar o seu problema. E eu ia responder
como outra pessoa aqui da lista que era possível utilizar outras linguagens
para resolver seu problema, mas você acabou com qualquer chances de resposta
dizendo que não queria alterar seu arquivo sql contendo a estrutura e as
funções do seu banco. ;-)
Porque tenho quase certeza de que se eu criasse uma versão em C do
fibonacci, o postgres acabaria com o pl do oracle. Yaaah!

Brincadeiras de lado... Você está certo.
Ocorre que: Em alguns momentos devemos usar métodos diferentes para resolver
problemas semelhantes em SGBDs diferentes. E isso é de se esperar. Não é
verdade?
Vale o mesmo quando comparado o SQL Server e Oracle.


Valeu!




2009/9/24 MARCIO CASTRO marciomouracas...@yahoo.com.br

  Caro Tarcísio:

   Achei muito interessante o seu teste, porém, você pode ter pecado na
 frase O que vale para outros SGBDS. O que eu tenho observado é que o
 Postgres é extremamente lento em DETERMINADAS situações, comparado ao SGBD
 Oracle, por exemplo.
   Há alguns dias atrás, postei um exemplo de uma função em PL/pgSQL que
 simplesmente realizava um loop, onde a cada interação, era somado +1 para
 uma variável. Fiz o mesmo no Oracle (11g), numa instalação de testes em um
 Celeron, e foi muito mais rápido!
   Na época, cheguei até a pensar que existia um problema no servidor, no
 Linux ou na instalação do PostgreSQL. Também não sei se este problema é
 específico do PL/pgSQL ou do PostgreSQL, mas o fato é que também ainda não
 achei nenhuma explicação para o ocorrido.


 Atenciosamente,

 Márcio de Figueiredo Moura e Castro



 --
 *De:* Tarcísio Sassara sassara.tarci...@gmail.com
 *Para:* fabriziome...@gmail.com; Comunidade PostgreSQL Brasileira 
 pgbr-geral@listas.postgresql.org.br
 *Enviadas:* Quinta-feira, 24 de Setembro de 2009 6:28:09
 *Assunto:* Re: [pgbr-geral] Memory (heap)

 Bom dia pra todos.

 Acompanhando as mensagens de perto, achei o assunto interessante e resolvi
 brincar um pouco.
 Mas antes, minha opinião:

 Se só quero usar o SGBD para armazenar dados temporários com direito a
 acesso muito rápido, talvez seja melhor usar outra abordagem que não
 empregue o postgres.
 Mas e se for o caso da aplicação a ser desenvolvida já faz uso do postgres?
 Se já tenho o banco rodando, mas tenho uma tabelinha sem vergonha que uso
 para armazenar algo descartável e que é mais importante um acesso rápido,
 eu, de primeira,
 pensaria em criar o tablespace temporário e engoliria o WAL, ou seja, vai
 ir para o WAL mas tudo bem. OK? Bom fiz alguns testes e não foi muito legal
 o resultado para esta abordagem.

 Fui para a maquina virtual fazer alguns benchmarks bem por cima.

 1º teste: instalação padrão.
 2º teste: instalação com todo o cluster e binários em um fs temporário.
 3º teste: instalação padrão com um tablespace temporário.

 Comandos do pgbench utilizados

 # inicializa as tabelas usadas pelo pgbench com um scale factor igual a
 10 no banco de dados postgres
 pgbench -i -s 10 postgres

 # roda o proprio benchmark com 10 conexões simultaneas 1000 vezes para cada
 uma destas.
 pgbench -c 10 -t 1000 postgres


 1º teste: Instalação padrão. Resultado:

  tps = 477.656061 (including connections establishing)
  tps = 478.578011 (excluding connections establishing)
 ---

 2º teste: Instalação com todo o cluster e binarios em um fs temporario:

 montei um tmpfs seguindo o comando de um dos links fornecidos pelo
 Fabrízio.
 Aumentei o tamanho do fs para conseguir rodar o pgbench:

 $ sudo mount -t tmpfs -o size=500M,uid=tarcisio,gid=tarcisio,mode=0700
 tmpfs /home/tarcisio/tmpfs
 configurei e instalei o postgres junto com o contrib tudo ai dentro.
 Rodei o pgbench:

  tps = 823.146755 (including connections establishing)
  tps = 825.540711 (excluding connections establishing)

 Quase o dobro. Porem, não vejo utilidade/praticidade em colocar o cluster
 inteiro junto com os binários do postgres dentro de um fs temporário.
 Se o que quero é algo bem simples e minha aplicação não utilizará o
 postgres pra nada alem disso, prefiro estudar outras ferramentas.

 ---

 3º teste: Instalação padrão com um tablespace temporário.

 Matei a instalação anterior. sudo umount /home/tarcisio/tmpfs
 Montei de novo com tudo limpo e criei o tablespace:
 =# CREATE TABLESPACE tmpfs OWNER tarcisio LOCATION '/home/tarcisio/tmpfs';

 ALTEREI o código fonte do pgbench para criar as tabelas e indices dentro do
 tablespace
 Disso: create table tabela_aqui
 Fiz isso: create table tabela_aqui TABLESPACE tmpfs
 E disso: alter table pgbench_*** add primary key (bid)
 Fiz isso: alter table pgbench_*** add primary key (bid) USING INDEX
 TABLESPACE tmpfs
 Compilei o pgbench de novo e rodei:

  tps = 453.644599 (including connections establishing)
  tps = 454.687999 (excluding connections establishing)

 Foi pior que a instalação padrão! Ou seja, talvez não seja uma boa opção.
 (ou benchmark mau feito)
 Se já uso o

Re: [pgbr-geral] Res: Res: Res: Memory (heap)