Re: [pgbr-geral] [off-topic] Only NoSQL
O grande problema na area de TI eh a falta de conceitos. Muitas decisoes sao tomadas baseadas em achismos ou casos isolados de sucesso. Os profissionais da nossa area nao tem o costume de ler artigos tecnicos, cientificos, pesquisas... Ai podemos perceber porque mais de 60% dos projetos de TI fracassam. Com relacao ao topico vou deixar aqui meus 2 cents. Em 6 de novembro de 2015 18:15, Rogério F.Santo <rogeriofsan...@gmail.com> escreveu: > So para deixar claro os termos usados como todo termo é usado diante de > contexto e uma literatura e bom saber isso antes de apontar falhas. No caso > dados não estrurados a que me refiro e o que consenso entre os grandes > players de mercado e no caso são documentos, vídeos, fotos e etc coisas > que se você quiser quardar em 8m banco diretamente você teria um campo blob > e não acho que alguém queira fazer um Where em um blob. Os nosql em geral > funcionam melhor com estes dados e tem implementação mais fácil. > Existe uma grande confusao aqui. Estamos misturando os conceitos de armazenamento, extracao, pesquisa, indexacao... Para armazenar arquivos a melhor alternativa ainda eh o sistema de arquivos. Arquivos binarios ou nao, seja qual for o formato, deixe a responsabilidade para o sistema de arquivos. Sobre indexar midias existem varios desafios e podemos perceber que de fato o termo "nao estruturado" nao cabe aqui pois todos possuem uma estrutura muito bem definida. Os desafios aqui remetem exatamente em decodificar tal estrutura. Eu vou considerar os documentos como "documentos texto", nao confundir com formato texto puro, tais como PDF's, arquivos M$ Word e formatos livre como ODT. Neste caso eh muito simples decodifica tais documentos, extrair os dados relevantes e indexa-los. O problema maior eh quando precisamos indexar imagens e videos. Nesse caso temos que utilizar tecnicas mais sofisticadas como visao artificial e existem muitas pesquisas nessa area e ate "concursos" que envolvem grandes empresas e universidades. Mas tudo isso nao tem absolutamente nada a ver com o banco de dados. Os dados sao extraidos utilizando-se tais tecnicas/algoritmos/bibliotecas/magica/vodoo. > Os relacionais para suprir este problema implementam o full text sach mas > nem todos ainda possuem está características. E por favor toda estrutura de > dados tem um algoritmo mas eficaz para realizar buscas sobre elas. Acho que > deixei bem claro estar falando do algoritmo e não dá forma como eles são > organizados no banco. > Novamente uma confusao sobre os conceitos. Para simplificar o conceito sobre full text search podemos pensar nele como uma pesquisa linguistica onde pode operar em palavras e frases com base em uma determinada regra a qual geralmente eh baseada em padroes linguisticos de idiomas especificos como ingles, chines, portugues, etc... Para finalizar, muito se fala em como os noSQL sao adotados "la fora". Bem, aqui fora os dados importantes ainda sao tratados com muito criterio e ainda precisa-se provar muita coisa. Existe muita publicidade sobre os noSQL e muitas empresas de fato estao ganhando muito dinheiro com isso. Eu ja conversei com no minimo uns 7 "consultores" noSQL apenas este ano os quais falavam das vantagens e de tudo o que poderiamos ganhar se adotassemos as solucoes deles. Eu acho muito interessante para armazenar sessao de usuario, cache, e em alguns casos como auxilio para DW e geracao de relatorios, graficos, etc... Eles tem sim seu uso mas nao sao tudo isso que falam e propagam por ai. PS. Desculpem-me pela falta de acentos mas ainda estou brigando com o meu teclado :-\ Abc, Charly Batista ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] armazenamento de imagens no Banco x File System
Um pouco atrasado no tópico mas vamos lá... Em 24 de outubro de 2016 20:15, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > > > Em seg, 24 de out de 2016 às 13:50, Luiz Henrique < > luiz.henriqu...@gmail.com> escreveu: > >> Pessoal, >> >> Temos uma aplicação jboss que recebemos como "herança", ela armazena >> diversos arquivos de imagens (jpeg,bmp,etc). Essa tabela com os binários >> representa mais que 90% do tamanho total do banco, hoje com 210GB. >> >> Aí vem a pergunta. O que os participantes do grupo acham dessa prática ? >> O que é mais indicado, gravar arquivos em file system ou no próprio banco ? >> Sendo file system vocês tem sugestão de ferramentas ? >> > > Não vejo boa prática nem em A nem em B. > Colocar arquivos em banco de dados tem suas vantagens, como por exemplo, > ter um backup unificado. Você também pode lidar com replicação dos dados e > dos arquivos simultaneamente. Sem contar que tudo se torna transacional, > portanto, você pode criar, modificar ou remover um arquivo ao mesmo tempo > que outra transação e o banco cuida do isolamento e atomicidade da coisa > toda. > Ter um sistema de arquivos separado pode ser interessante quando você tem > muitos acessos aos arquivos, isso é mais fácil de escalar que o banco de > dados. Por outro lado, ao contrário do controle transacional que falei > acima, é muuuito comum arquivos ficarem perdidos no sistema de arquivos > sendo que o "caminho" já foi removido do banco de dados. > > Enfim, cada caso é um caso, acho que simplesmente o "tamanho do banco" e > "uma grande tabela" não é fator de decisão ou exclusão. > Como bem colocado pelo Gurgel o simples fato do "tamanho do banco" não é um bom indicativo para qualquer mudança e cada caso é um caso. Todavia, como regra geral, sistemas de arquivos lidam melhores com arquivos do que SGBD's. Toda vez que você adiciona uma nova camada de abstração, neste caso o banco de dados, você não apenas pode perder em performance mas adiciona um nível maior de complexidade que pode causar problemas indesejados, como por exemplo corrupção dos arquivos armazenados no banco. Com relação as vantagens do SGBD sobre o FS eu não vejo tanto ganho assim. Por exemplo, não é preciso perder as vantagens transacionais ao colocar toda a operação, incluindo as chamadas ao FS, na mesma transação. Pode-se colocar as alterações no FS pro final da transação e em último caso pode-se utilizar ferramentas de versionamento para garantir que o estado do sistema de arquivos esteja consistente e em um caso onde o FS retorne um erro basta executar um rollback. Com relação ao backup não vejo como vantagem tão grande uma vez que de qualquer forma devemos ter uma boa estratégia para ambos, SGBD e FS. Por outro lado concentrar os arquivos no BD irá aumenta o tempo de backup e principalmente o tempo de recuperação pois fica mais complexo a aplicação de paralelismo. Outro ganho que se pode ter com arquivos no FS é a utilização de servidores para mídias e arquivos estáticas. Muito mais eficientes e pode-se utilizar CDN para distribuir a carga através da rede o que descentraliza o tráfego e melhora performance. Mas como foi falado acima pelo Gurgel, se não existe um problema real não vejo porque mudar pelo simples fato de as tabelas estarem crescendo. Att, Charly Batista ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Criar ou não Indices para Contraints
Pessoal, sempre lembrando, vamos evitar "top posting" com este meu comentário aqui, isto atrapalha muito!!! Em 14 de outubro de 2016 01:55, Fernando Franquini 'capin' < fernando.franqu...@gmail.com> escreveu: > Euler, > > Eu trabalhei bastante com Oracle e SQL Server, posso afirmar que faziam > diferença e concordo com os pontos (i) e (ii). > > Porém em relação a junção fiquei em dúvida no item (iii): > > Se a PK da tabela A é FK na tabela B, ao realizar a junção de A com B e > usar a coluna FK vai usar o indice da PK na A e na B nada?? > > Obrigado pelas colocações. > Abraços. > > 2016-10-13 11:16 GMT-03:00 Euler Taveira <eu...@timbira.com.br>: > >> On 13-10-2016 08:37, Fernando Franquini 'capin' wrote: >> > Mas em princípio ele deve fazer mais bem que mal, porque? Porque toda >> > junção com as chaves (FKs) que forem realizadas irão utilizar esse >> índice. >> > >> Isso pode ser verdade em outros bancos (que criam índice para cada FK); >> no postgres isso não é. É uma prática comum (criar esses índices) mas eu >> particularmente não recomendo porque (i) ocupa espaço, (ii) torna >> operações de INSERT, UPDATE e DELETE lentas (porque é necessário manter >> os índices atualizados) e (iii) junções vão usar o índice da chave >> primária e não o índice da FK. Quando esses índices são úteis? Em >> consultas que não fazem a junção com a tabela da chave primária e a >> cláusula WHERE inclui o campo da FK (e os valores utilizados são >> seletivos). >> >> Nos diversos modelos que trabalhei atrevo a dizer que menos de 2% das >> consultas vão se beneficiar de um índice em um campo que é FK. Portanto, >> eu prefiro ir criando esses índices em FK sob demanda. Em modelos >> consolidados, faz-se uma análise de todas as consultas e os planos de >> execução vão dizer se o índice na FK é benéfico ou não. >> >> Em modelos migrados de outros SGBDs, após uma análise de uso, observa-se >> que a maioria dos índices candidatos a remoção são em FK. > > Com relação a questão de se criar indices para restrições de chave estrangeira, como o Eula já colocou isso é desnecessário na maioria dos casos. Onde seria interessante se criar? Cito aqui 3 situações que ajudam: - Quando você tem operações em cascata. Isso vai ajudar na melhoria de performance e de fato pode ser dramática a diferença de performance. - Quando a junção é no sentido da tabela pai para a tabela filha. Como já dito também, nem toda junção vai fazer uso do índice na tabela filha. Por exemplo quando a junção é no sentido da tabela filha para a tabela pai vai fazer uso do índice de chave na tabela pai pois os registros da tabela filha já foram pré-selecionados. No caso de uma junção onde se busca no sentido da tabela pai para a filha o otimizador pode fazer a escolha por utilizar o índice em casos onde haja um bom nível de seletividade o que melhora a performance. Como as operações acima não são frequentes, por exemplo é muito mais comum pesquisar um produto e fazer a junção dele com a categoria do que pesquisar a categoria e trazer todos os produtos vinculados. Aqui mesmo com índice dependendo da seletividade o otimizador pode escolher não fazer uso do índice. Portanto, se você altera com frequência a chave primária, remove os registros da tabela pai com frequência ou seleciona os registros partindo da tabela pai pra tabela filha com frequência e o índice possui índice de seletividade suficiente então um índice faria sentido. Lembro que operações em cascata são perigosas e, EU (opinião pessoal aqui) particularmente não recomendo. Sem contar que são raros os casos onde realmente são necessárias. Charly Batista ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7
Eduardo, vamos por partes, /LC_COLLATE = 'pt_BR-ISO-8859-1' LC_CTYPE = 'pt_BR-ISO-8859-1'/ >>> >> /Olá Eduardo, >> reparei que estais usando um hífen separando pt_BR de ISO-8859-1, onde >> me parece que deveria haver um ponto. >> >> Experimente assim: >> >> / >> >> /LC_COLLATE = 'pt_BR.ISO-8859-1' LC_CTYPE = 'pt_BR.ISO-8859-1' Att. Alex / >> >> >> > corrigi, porem, deu erro tb. > > ERROR: encoding "UTF8" does not match locale "pt_BR.ISO-8859-1" > DETAIL: The chosen LC_CTYPE setting requires encoding "LATIN1". > ** Error ** > > ERROR: encoding "UTF8" does not match locale "pt_BR.ISO-8859-1" > SQL state: 22023 > Detail: The chosen LC_CTYPE setting requires encoding "LATIN1". > No teu primeiro email você cita "Portuguese_Brazil.1252". Faz muito tempo que eu não uso windows e esse encoding está com um nome um pouco diferente do que eu costumava ver mas reconheço o "1252". Infelizmente "Windows-1252" é quase um ISO-8859-1 mas não é. Existem algumas sequencias de caracteres que são diferentes o que provoca erros. Outro problema é que no windows UTF8 pode ser utilizado com qualquer locale enquanto que no linux não, isso é um pouco mais organizado. Ao invés de utilizar o locate pt_BR.ISO-8859-1 tenta utilizar pt_BR.UTF8. Att, Charly Batista ___ 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 com Docker
Opa, vou deixar aqui meus 2 cents. Em 5 de julho de 2017 07:18, Lucas Viecelli <lviecelli...@gmail.com> escreveu: > Boa noite. > > Nessas ultimas semanas andei realizando alguns testes do PostgreSQL com > Docker afim de ter um ambiente de desenvolvimento mais dinâmico, e também > para facilitar testes com diversas versões do PostgreSQL. Esses testes se > mostraram bastantes estáveis e quero saber: > > Alguém utiliza o PostgreSQL com Docker em um ambiente de produção? > Eu conheço uns 2 ou 3 casos que estão dando certo mas são aplicações específicas e pequenas e utilizam conteiners para o que eles, na minha visão, foram criados para fazer, prover um nível aceitável de isolamento. > > Eu sei que escalar o PostgreSQL não é tão simples como escalar um servidor > de aplicação. Mas quero saber as experiencias que vocês tem com essa dupla > num ambiente real. > Conteiners não foram criados para prover escalabilidade. Existem poucas aplicações que se beneficiariam de conteiners pra prover escalabilidade, e essas são aplicações desprovidas de multi-processamento. Conteiners vão apenas te propiciar um certo nível de isolamento dentro do teu box onde você pode ter aplicações que poderiam competir por recursos trabalharem armoniozamente. Com relação a escalabilidade existem dois tipos, vertical - quando você adiciona mais poder computacional ao teu servidor- e horizontal - quando você adiciona mais servidores ao teu parque computacional. Com docker você não adiciona nada, você divide, portanto perde-se o conceito. Todavia, como eu falei anteriormente, você pode se beneficiar em ter mais de uma instancia da mesma aplicação rodando no mesmo box, por exemplo Redis. É uma ferramenta extraordinária mas não faz uso de muiti processos, utiliza apenas um processo. Se você tiver um box com multiplos núcleos e memoria suficiente pode ser mais benéfico ter várias instancias executando no mesmo box do que ter diversos boxes distribuidos pela rede. Mas aplicações multiprocesso como PG não tem ganho algum com docker, excetuando-se raros casos onde se compartilha o box entre o banco e outras aplicações, mas como outro colega colocou, pode ser complexo e dispendioso. Ressalvadas essas observações, quando bem utilizado o docker é uma ferramenta interessante. Não é muito explorado no mundo corporativo mas vem sendo bastante explorado por provedores de hospedagem e times de desenvolvimento. Att, Charly Batista ___ 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 ao tentar inserir um array de bytes
Daniel, Campos binários em geral são um problema dentro do hibernate (vou ser sincero, não gosto muito de ORM's ... rsss) Segue um exemplo simples utilizando JDBC direto, que acho bem mais simples... File file = new File(myimage.gif); FileInputStream fis = new FileInputStream(file); PreparedStatement ps = conn.prepareStatement(INSERT INTO images VALUES (?, ?)); ps.setString(1, file.getName()); ps.setBinaryStream(2, fis, (int)file.length()); ps.executeUpdate(); ps.close(); fis.close(); Para maiores detalhes, dá uma olhada em http://jdbc.postgresql.org/documentation/80/binary-data.html Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/7/23 Daniel Henrique Joppi daniel.jo...@gmail.com adicionei a propriedade property name=defaultAutoCommit value=false / como sugerido em outros tópicos na internet ... alguém conhece uma outra maneira? On Wed, Jul 22, 2009 at 9:46 AM, Daniel Henrique Joppi daniel.jo...@gmail.com wrote: Bom dia, Estou com problemas ao tentar inserir um array de bytes em um campo do tipo oid. org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [com.norxs.mama.MyMessage]; uncategorized SQLException for SQL [insert into public.MyMessage (isProtocol, domain, sourceID, service, flow, priority, status, createdOn, message, props, uniqueid, messageType, nrDoc, fromPartner, toPartner, messageSize, billingTo, processedOn, billing, groupType, messageIdKey) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; SQL state [25P01]; error code [0]; Objetos Grandes não podem ser usados no modo de efetivação automática (auto-commit).; nested exception is org.postgresql.util.PSQLException: Objetos Grandes não podem ser usados no modo de efetivação automática (auto-commit). at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:121) at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:322) at org.springframework.orm.hibernate3.HibernateAccessor.convertJdbcAccessException(HibernateAccessor.java:424) at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:410) at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:378) at org.springframework.orm.hibernate3.HibernateTemplate.save(HibernateTemplate.java:639) at com.norxs.mama.DBPersistence.messageArrived(DBPersistence.java:411) at com.norxs.mama.jbi.ReceiverLegacyMonoComponent.poll(ReceiverLegacyMonoComponent.java:98) at org.apache.servicemix.components.util.PollingComponentSupport.run(PollingComponentSupport.java:65) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.postgresql.util.PSQLException: Objetos Grandes não podem ser usados no modo de efetivação automática (auto-commit). at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:241) at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:228) at org.postgresql.jdbc2.AbstractJdbc2Statement.setBlob(AbstractJdbc2Statement.java:2851) at org.apache.commons.dbcp.DelegatingPreparedStatement.setBlob(DelegatingPreparedStatement.java:181) at org.hibernate.type.BlobType.set(BlobType.java:49) at org.hibernate.type.BlobType.nullSafeSet(BlobType.java:117) at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2002) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2248) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2665) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:60) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.springframework.orm.hibernate3.HibernateAccessor.flushIfNecessary(HibernateAccessor.java:390) at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:374) ... 7 more -- [ ]'s Daniel Henrique Joppi msn: no...@hotmail.com gtalk: daniel.jo...@gmail.com skype: daniel.joppi -- [ ]'s Daniel Henrique Joppi msn
Re: [pgbr-geral] Erro ao tentar inserir um array de bytes
Daniel, não é nem problema com o driver, mas sim como o DB trata os dados
binários... Diferentemente dos dados planos, dados binários você tem que
trabalhar com fluxo de dados... De uma maneira bem grosseira, vai escrever
como se estivesse escrevendo em um fluxo de arquivo convencional... Logo, só
deve realizar o commit quando o fluxo terminar com sucesso. Neste caso, não
é exclusividade do PostgreSQL.
Att,
2009/7/23 Daniel Henrique Joppi daniel.jo...@gmail.com
Charly,
Obrigado pelo retorno. Vou dar uma analisada melhor no hibernate, talvez
tenhamos que fazer algumas modificações nele.
Não temos como remove-lo pois é o utilizamos a muito tempo, e agora quando
fomos atualizar a versão de outro banco notamos o mesmo problema com campos
binários.
Mas voltando ao Postgres notei que na própria API de conexão não me deixa
enviar meu dados se tiver com o AutoComit:
na classe *org.postgresql.largeobject.LargeObjectManager*
*public *LargeObject open(long oid, int mode) *throws *SQLException
{
*if* (conn.getAutoCommit())
*throw new* PSQLException(GT.tr(Large Objects may not be used
in auto-commit mode.),
PSQLState.*NO_ACTIVE_SQL_TRANSACTION*
);
*return new *LargeObject(fp, oid, mode);
}
então não seria só problema do hibernate, mas sim do driver de conexão
também? Alguém tem idéia o porque disso?
On Thu, Jul 23, 2009 at 4:14 PM, Charly Frankl carl...@gmail.com wrote:
Daniel,
Campos binários em geral são um problema dentro do hibernate (vou ser
sincero, não gosto muito de ORM's ... rsss) Segue um exemplo simples
utilizando JDBC direto, que acho bem mais simples...
File file = new File(myimage.gif);
FileInputStream fis = new FileInputStream(file);
PreparedStatement ps = conn.prepareStatement(INSERT INTO images VALUES
(?, ?));
ps.setString(1, file.getName());
ps.setBinaryStream(2, fis, (int)file.length());
ps.executeUpdate();
ps.close();
fis.close();
Para maiores detalhes, dá uma olhada em
http://jdbc.postgresql.org/documentation/80/binary-data.html
Att,
--
Charly Frankl
http://javadevilopers.blogspot.com/
charlyfra...@gmail.com
Linux user #391083
2009/7/23 Daniel Henrique Joppi daniel.jo...@gmail.com
adicionei a propriedade property name=defaultAutoCommit value=false
/ como sugerido em outros tópicos na internet ...
alguém conhece uma outra maneira?
On Wed, Jul 22, 2009 at 9:46 AM, Daniel Henrique Joppi
daniel.jo...@gmail.com wrote:
Bom dia,
Estou com problemas ao tentar inserir um array de bytes em um campo do
tipo oid.
org.springframework.jdbc.UncategorizedSQLException: Hibernate operation:
could not insert: [com.norxs.mama.MyMessage]; uncategorized SQLException
for
SQL [insert into public.MyMessage (isProtocol, domain, sourceID, service,
flow, priority, status, createdOn, message, props, uniqueid, messageType,
nrDoc, fromPartner, toPartner, messageSize, billingTo, processedOn,
billing,
groupType, messageIdKey) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?)]; SQL state [25P01]; error code [0]; Objetos Grandes
não podem ser usados no modo de efetivação automática (auto-commit).;
nested
exception is org.postgresql.util.PSQLException: Objetos Grandes não podem
ser usados no modo de efetivação automática (auto-commit).
at
org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:121)
at
org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:322)
at
org.springframework.orm.hibernate3.HibernateAccessor.convertJdbcAccessException(HibernateAccessor.java:424)
at
org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:410)
at
org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:378)
at
org.springframework.orm.hibernate3.HibernateTemplate.save(HibernateTemplate.java:639)
at
com.norxs.mama.DBPersistence.messageArrived(DBPersistence.java:411)
at
com.norxs.mama.jbi.ReceiverLegacyMonoComponent.poll(ReceiverLegacyMonoComponent.java:98)
at
org.apache.servicemix.components.util.PollingComponentSupport.run(PollingComponentSupport.java:65)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.postgresql.util.PSQLException: Objetos Grandes não podem
ser usados no modo de efetivação automática (auto-commit).
at
org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:241)
at
org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:228)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.setBlob(AbstractJdbc2Statement.java:2851
Re: [pgbr-geral] Parse
Kaui, bom dia... Pelo que você escreveu: preparete query - execute query - dealocate preparetequery Bem, isso ao meu ver não faz sentido... você está indicando ao banco que realize o parse toda vez que a consulta seja realizada com o dealocate. Se a consulta é utilizada repetidas vezes dentro da seção aberta, não precisa remove-la do plano de consultas (dealocate), pois vai perder todo o benefício que o prepare te dá. Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/7/30 Kauí Aires Oliveira kauiai...@gmail.com Bom Dia Osvaldo... Exatamente é o que estamos conjurando ser a aplicação, pois tem outra aplicação que não utiliza a Zend como frame work e faz todo esse procedimento e não está acontecendo isso... Suspeito que seja algum parâmetro ativo algo do gênero... Mas é exatamente isso é uma consulta que é executada N vezes... Mas até agora o problema persiste :( 2009/7/29 Osvaldo Kussama osvaldo.kuss...@gmail.com 2009/7/29 Kauí Aires Oliveira kauiai...@gmail.com: Olá Dickson Não usamos ORM vem da zend direto a aplicação... o erro é porque qualquer query que seja executada faz o seguinte preparete query - execute query - dealocate preparetequery E quando o sistema tenta passar alguma coisa ele faz o parse e o dealocate da assinatura do preparete... Se eu entendi corretamente o problema está em sua aplicação. A vantagem de usar o PREPARE é que o PostgreSQL analisa, reescreve e planeja uma única vez e cada EXECUTE apenas executa com os parâmetros recebidos. Só tem sentido se um determinado modelo de query vai ser executado múltiplas vezes, não faz sentido usar este procedimento *a cada query*. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NOT NULL
Sergio, bom dia... Basta utilizar uma trigger. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/7/30 sergio santos sergio.serginhos...@gmail.com Pessoal, eu consigo colocar uma restrição em um campo de uma tabela para ser NOT NULL. No entanto eu não consigo, por exemplo, colocar uma restrição para um campo do tipo character varying(30) não receber vazio. O que tô querendo dizer é que NULL e vazio é diferente. E o que estou querendo saber é como colocar uma restrição no banco de dados para ele não receber valor vazio. abraços -- Sérgio Antônio dos Santos Bacharel em Sistemas de Informação (31) 8573-7004 http://serginhosant.wordpress.com/ http://www.rccvicosa.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Res: Res: Res: Analise de uso de index entre 8.2 ou 8.3
Paulo, boa tarde... No teu email inicial, você disse que criou o indice xix1_cliente em desenv e resolveu, mas não resolveu em produção. Olhando o teu explain, podemos ver que um dos pontos de impacto, como falado anteriormente é a entidade logradouro_bairro: Desenv: - Index Scan using logradouro_bairro_pkey on logradouro_bairro logradouro3_ (cost=0.00..6.07 rows=1 width=8) (actual time=9.047..9.048 rows=1 loops=284) Index Cond: (logradouro3_.lgbr_id = clienteend2_.lgbr_id) Produção: - Seq Scan on logradouro_bairro logradouro3_ (cost=0.00..2033.86 rows=117186 width=8) (actual time=0.011..359.858 rows=117186 loops=1) Temos um acesso sequencial ai... E nesse ponto, o custo da consulta comeca a ficar muito elevada. Dá uma olhada nessa entidade em produção... Se para o atributo em questão você tem um indice... Outra coisa, para melhorar um pouco o banco na hora do parse, inverta a ordem dos atributos no teu relacionamento (o analisador de consultas provavelmente vai fazer isso pra vc, mas não custa nada dar uma maozinha... rsss), algo como: select count(distinct cliente0_.clie_id) as col_0_0_ from cadastro.cliente cliente0_ left outer join cadastro.cliente_tipo clientetip1_ on clientetip1_.cltp_id = cliente0_.cltp_id left outer join cadastro.cliente_endereco clienteend2_ on clienteend2_.clie_id = cliente0_.clie_id left outer join cadastro.logradouro_bairro logradouro3_ on logradouro3_.lgbr_id = clienteend2_.lgbr_id left outer join cadastro.bairro bairro4_ on bairro4_.bair_id = logradouro3_.bair_id left outer join cadastro.municipio municipio5_ on municipio5_.muni_id = bairro4_.muni_id where (upper(cliente0_.clie_nmcliente) like 'EDNALDO F%') and municipio5_.muni_id=960 Considere também a possibilidade de substituir os left outer join por inner join (como falado tb), claro se a lógica do sistema permitir... Pois o custo de outer joins pro banco é alto... Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/7/31 paulo matadr saddon...@yahoo.com.br Boa tarde euler, nao houve mudanca no plano..fui ate 64 de work e nada -- *De:* Euler Taveira de Oliveira eu...@timbira.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Quarta-feira, 29 de Julho de 2009 18:14:19 *Assunto:* Re: [pgbr-geral] Res: Res: Analise de uso de index entre 8.2 ou 8.3 paulo matadr escreveu: Os parametros do servidor aparentemente importantes sao: Qual é o valor de work_mem? Você tentou fazer: SET work_mem to 16MB; EXPLAIN ANALYZE SELECT ...; SET work_mem to 8MB; EXPLAIN ANALYZE SELECT ...; SET work_mem to 32MB; EXPLAIN ANALYZE SELECT ...; O plano mudou? Outra coisa é que você está utilizando LEFT JOIN em todas as junções. Eles são realmente necessários ou tem algum deles que pode ser um INNER JOIN (aqueles cuja chave estrangeira não pode ser nula)? Junções externas *não* restringem tanto o conjunto de dados quanto junções internas e, tendem a ser mais custosas. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/- Celebridadeshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/- Músicahttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/- Esporteshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Proposta de estudo sobre definiçã o de índices de BD
utilizados mas em casos raros e não trariam maiores problemas caso ele fosse removido. No caso da estratégia (iv), podemos ter que decompor um índice para que mais consultas possam se beneficiar deles ou Assim, os SGBDs possuem ferramentas de análise (a posteriori) para definir se índices são úteis ou não e sugerir a criação caso sejam benéficos. Vide a ferramenta [3] ou os trabalhos do Prof. Sergio [4]. [1] http://wiki.postgresql.org/wiki/Database_Administration_and_Maintenance [2] http://wiki.postgresql.org/wiki/Portugu%C3%AAs [3] http://pgfoundry.org/projects/pgadviser/ [4] http://www.inf.puc-rio.br/~postgresql/index.php?acao=grupopesquisahttp://www.inf.puc-rio.br/%7Epostgresql/index.php?acao=grupopesquisa -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Otimizacao delete
Paulo, boa tarde... Consultas com clausulas in em geral sao um problema, pois vc acaba tendo duas matrizes... No teu caso, o banco escolheu por fazer um acesso sequencial na tabela, foi menos custoso para ele. Com relacao ao indice ai, nao sei se adiantaria, pois ele teria que fazer um nested loop... Para cada registro selecionado na entidade A localizar o correspondente na entidade B... Existe a possibilidade de ser bem mais custoso... Talvez por isso as outras consultas nao surtiram muito efeito... Bem, com relacao a sugestoes, desculpe-me por nao ajudar por enqto, mas nao deu pra analisar com mais cuidado uma solucao alternativa... Creio que amanha consiga ter um pouco mais de tempo, e se tiver alguma ideia, posto aki. Att, 2009/8/4 paulo matadr saddon...@yahoo.com.br Olha pessoal, Eu to com esse delete na maior tabela do meu banco: delete from cobranca_documento_item where cnta_id in (select cnta_id from conta_geral where cntg_ichistorico=3) que ta sendo muito custoso para nosso ambiente,no analyze Hash IN Join (cost=444791.95..11042547.76 rows=1390453 width=6) Hash Cond: (cobranca_documento_item.cnta_id = conta_geral.cnta_id) - Seq Scan on cobranca_documento_item (cost=0.00..5242127.64 rows=245865664 width=10) - Hash (cost=438290.02..438290.02 rows=373994 width=4) - Bitmap Heap Scan on conta_geral (cost=7278.42..438290.02 rows=373994 width=4) Recheck Cond: (cntg_ichistorico = 3) - Bitmap Index Scan on xix1_conta_geral (cost=0.00..7184.92 rows=373994 width=0) Index Cond: (cntg_ichistorico = 3) Estrutura: -Fk de cobranca_documento_item pra conta_geral ligando os campos cnta_id -Index para cnta_id em cobranca_documento_item(nao usando neste explain) -cnta_id em conta_geral é uma pk -Index para cntg_ichistorico em conta_geral( xix1_conta_geral) Existe uma maneira de fazer um delete mais otimizado n qual nao haja seqscan em cobranca_documento_item ? -- Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/- Celebridadeshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/- Músicahttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/- Esporteshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação
Walter, bom dia... Para replicação você dispõe de algumas opções no universo PostgreSQL. Para escolher a ideal no teu caso, tem-se que ver o quanto está disposto a correr risco de perda de dados (quanto de perda é aceitável), impactos na performance do sistema, disponibilidade do sistema (por quanto tempo eu posso ficar com o sistema indisponível), custo operacional de implantação, tempo gasto para recuperar os dados, dentre outras coisas. Tendo ponderado sobre isso, pode-se optar por um modelo síncrono ou assíncrono. Dentre as soluções assíncronas posso destacar: Slony Warm Standby Bucardo SkyTools Mammoth Dentre as soluções síncronas: PgPool-II Log Shipping Sequoia *ParGRES (desenvolvido pelo pessoal do UFRJ... bem interessante) *GridSQL (desenvolvido pelo pessoal da EnterpriseDB. Tb vale a pena dar uma olhada) Existem outras soluções também, como o PGCluster... Algumas destas soluções não se propõem apenas a replicação, mas também a balanço de carga, pool de conexões... Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/5 Walter Maier Neto wmaie...@yahoo.com.br Atualmente temos 4 servidores, todos de trabalho, replicando entre si (multi-master) com uma aplicação proprietária (de terceiros) que utiliza dblink e trigger. Mas este modelo está apresentando alguns problemas/restrições em relação ao ERP que é não é da mesma empresa da replica. Estamos pensando em utilizar replicação para contingência (alta disponibilidade) e não mais para balanceamento de carga, ou seja, utilizar o servidor principal para trabalho e o segundário como espelho do primeiro, sendo somente utilizado em caso de crash no principal; Busco mais informações práticas e consultoria especializada sobre o assunto; Grato; Walter Maier Neto Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação
Blz... Sorte nos teus testes, e podendo ajudar, basta perguntar. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/6 Walter Maier Neto wmaie...@yahoo.com.br O risco de perda de dados deve ser minimizado ao máximo, mas além disso, o custo da indisponibilidade é muito alto. Tolerada por períodos curtos, de 1 a 2 horas na pior hipótese, mas nunca superior a isso. Mas o objetivo é que, tanto a perda de dados como a indisponibilidade sejam eliminadas (estatisticamente); Atualmente a solução é assincrona, e esse não é nosso problemas. A preocupação com replicação sincrona é uma possível perda de performance, pois o servidor slave está em outro site (por segurança), e mesmo interligado através de um link profissional, tem performace muito inferior que uma rede local. Nosso volume de dados é considerável. Grato pela referência abaixo, vou dar uma pesquisada e começar os pilotos; Att; Walter Maier Neto Guarapuava/PR - Mensagem original - De: Charly Frankl carl...@gmail.com Para: Walter Maier Neto wmaie...@yahoo.com.br, Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quinta-feira, 6 de Agosto de 2009 9:36:43 (GMT-0300) Auto-Detected Assunto: Re: [pgbr-geral] Replicação Walter, bom dia... Para replicação você dispõe de algumas opções no universo PostgreSQL. Para escolher a ideal no teu caso, tem-se que ver o quanto está disposto a correr risco de perda de dados (quanto de perda é aceitável), impactos na performance do sistema, disponibilidade do sistema (por quanto tempo eu posso ficar com o sistema indisponível), custo operacional de implantação, tempo gasto para recuperar os dados, dentre outras coisas. Tendo ponderado sobre isso, pode-se optar por um modelo síncrono ou assíncrono. Dentre as soluções assíncronas posso destacar: Slony Warm Standby Bucardo SkyTools Mammoth Dentre as soluções síncronas: PgPool-II Log Shipping Sequoia *ParGRES (desenvolvido pelo pessoal do UFRJ... bem interessante) *GridSQL (desenvolvido pelo pessoal da EnterpriseDB. Tb vale a pena dar uma olhada) Existem outras soluções também, como o PGCluster... Algumas destas soluções não se propõem apenas a replicação, mas também a balanço de carga, pool de conexões... Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/5 Walter Maier Neto wmaie...@yahoo.com.br Atualmente temos 4 servidores, todos de trabalho, replicando entre si (multi-master) com uma aplicação proprietária (de terceiros) que utiliza dblink e trigger. Mas este modelo está apresentando alguns problemas/restrições em relação ao ERP que é não é da mesma empresa da replica. Estamos pensando em utilizar replicação para contingência (alta disponibilidade) e não mais para balanceamento de carga, ou seja, utilizar o servidor principal para trabalho e o segundário como espelho do primeiro, sendo somente utilizado em caso de crash no principal; Busco mais informações práticas e consultoria especializada sobre o assunto; Grato; Walter Maier Neto Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] funcionamento do driver postgresql-8.4...jdbc4.jar
Qual a versão do driver vc está utilizando? 2009/8/7 jorge sanfelice jorgesanfel...@gmail.com Prezados, É normal isso no funcionamento dos driver's jdbc para o postgresql (eu achei que isso era gerado pelo pool de conexoes, mais descobri que é relacionado ao driver mesmo): ... duração: 0.897 ms análise de unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duração: 0.137 ms ligação unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duration: 0.182 ms executar unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 Pergunto isso, porque nao sei que impacto a repeticao dos comandos pode gerar na performance do banco ou na quantidade de transacoes executadas. Alguem conhece bem isso para me dizer se é uma característica normal ou se pode causar problema esse tipo de funcionamento? Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] funcionamento do driver postgresql-8.4...jdbc4.jar
Jorge, boa tarde... Esse comportamento é bem típico de conexão em modo de DEBUG. O driver dá suporte a isso, e a documentação diz: loglevel = int Set the amount of logging information printed to the DriverManager's current value for LogStream or LogWriter. It currently supports values of org.postgresql.Driver.DEBUG (2) and org.postgresql.Driver.INFO (1). INFOwill log very little information while DEBUG will produce significant detail. This property is only really useful if you are a developer or are having problems with the driver. Bem, apesar de não tenho muitas informações sobre tua aplicação (conexão, versão de vm, servidor de aplicações, etc...) vou chutar esta possibilidade... rss Com relação ao impacto, claro que o fato de estar logando essas informações acarretará prejuízo... é mais um processo pra fila... No mais, [ ]'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/10 jorge sanfelice jorgesanfel...@gmail.com Em um server 8.4 driver postgresql-8.4...jdbc4.jar em um server 8.3 driver postgresql-8.3...jdbc3.jar Resumindo, nas duas versoes do driver faz a mesma coisa. 2009/8/10 Charly Frankl carl...@gmail.com: Qual a versão do driver vc está utilizando? 2009/8/7 jorge sanfelice jorgesanfel...@gmail.com Prezados, É normal isso no funcionamento dos driver's jdbc para o postgresql (eu achei que isso era gerado pelo pool de conexoes, mais descobri que é relacionado ao driver mesmo): ... duração: 0.897 ms análise de unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duração: 0.137 ms ligação unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duration: 0.182 ms executar unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 Pergunto isso, porque nao sei que impacto a repeticao dos comandos pode gerar na performance do banco ou na quantidade de transacoes executadas. Alguem conhece bem isso para me dizer se é uma característica normal ou se pode causar problema esse tipo de funcionamento? Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] funcionamento do driver postgresql-8.4...jdbc4.jar
Flw irmao!!! [ ]'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/10 jorge sanfelice jorgesanfel...@gmail.com Opa, Muito obrigado pela ajuda ai. Vou dar uma analisada nisso que me passou e qualquer duvida volto a postar. 2009/8/10 Charly Frankl carl...@gmail.com: Jorge, boa tarde... Esse comportamento é bem típico de conexão em modo de DEBUG. O driver dá suporte a isso, e a documentação diz: loglevel = int Set the amount of logging information printed to the DriverManager's current value for LogStream or LogWriter. It currently supports values of org.postgresql.Driver.DEBUG (2) and org.postgresql.Driver.INFO (1). INFO will log very little information while DEBUG will produce significant detail. This property is only really useful if you are a developer or are having problems with the driver. Bem, apesar de não tenho muitas informações sobre tua aplicação (conexão, versão de vm, servidor de aplicações, etc...) vou chutar esta possibilidade... rss Com relação ao impacto, claro que o fato de estar logando essas informações acarretará prejuízo... é mais um processo pra fila... No mais, [ ]'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/10 jorge sanfelice jorgesanfel...@gmail.com Em um server 8.4 driver postgresql-8.4...jdbc4.jar em um server 8.3 driver postgresql-8.3...jdbc3.jar Resumindo, nas duas versoes do driver faz a mesma coisa. 2009/8/10 Charly Frankl carl...@gmail.com: Qual a versão do driver vc está utilizando? 2009/8/7 jorge sanfelice jorgesanfel...@gmail.com Prezados, É normal isso no funcionamento dos driver's jdbc para o postgresql (eu achei que isso era gerado pelo pool de conexoes, mais descobri que é relacionado ao driver mesmo): ... duração: 0.897 ms análise de unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duração: 0.137 ms ligação unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 duration: 0.182 ms executar unnamed: SELECT veioid,veiplaca FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE logvlogoid = 6 Pergunto isso, porque nao sei que impacto a repeticao dos comandos pode gerar na performance do banco ou na quantidade de transacoes executadas. Alguem conhece bem isso para me dizer se é uma característica normal ou se pode causar problema esse tipo de funcionamento? Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BLOQUEIO DE REGISTRO
Miguel, boa noite... Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem opções, onde para retornar logo que está ocupado utilize NOWAIT. Att, 2009/8/11 JotaComm jota.c...@gmail.com Olá, Miguel Já comentei no email anterior e fiz uma pequena descrição de como isso funciona. Você deu uma olhada no exemplo que mandei? O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita (UPDATE e DELETE). 2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br Oi Mário, Este é o problema a leitura nunca é bloqueada. Fiz os testes pedidos, mas para mim não mudou nada! Veja: - Na sessão 1: db_teste=# BEGIN WORK; BEGIN db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT; LOCK TABLE db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where codg_serma='10'; UPDATE 1 db_teste=# *** aguardando novo comando *** - Na sessão 2: db_teste=# BEGIN WORK; BEGIN db_teste=# SELECT * FROM tab_material where codg_serma='10'; codg_empr | codg_serma | id_serma | desc_serma ---++++--+-- 202 | 10 | 202010 | LAPIS Y| É isso ai!!!?? Obrigado. 2009/8/11 Mário Oshiro mario.osh...@gmail.com Em SQLServer, fiz um teste parecido com o seu. Qdo vc faz um lock de registro ou trabela, ele nao bloqueia a leitura de outras sessoes, ate' que a sessao de posse do lock, faça um update de algum dado do registro. Para bloquear o select que vc fez, faca em seguida um update com a mesmo where assim : db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE; update tab_material set codg_serma='10' where codg_serma='10' ; teste la e depois envie o resultado. até mais. MIGUEL JOSE DE LIMA wrote: Caros, participantes... Sou iniciante neste mundo do PostgreSQL. Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME), mas me incubiram de fazer testes no PostgreSQL para bloquer registros. Então... Estou precisando de ajuda para bloquear a leitura de um registro, ou seja, em um cenário como: Atualização de Estoque de um Material : Antes de atualizar o estoque do material selecionado eu preciso bloquear o registro para que nenhuma outra sessão possa obter o dado do registro. PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA. Estou usando o PostgreSQL 8.3.7 para os testes - em linux Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não esteja entendendo...??? Fiz o seguinte teste via psql: - Na Sessão A db_teste=# BEGIN WORK; BEGIN db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT; LOCK TABLE db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE; resultado obtido ok! *** aqui eu preciso bloquear todos os materiais/itens (de um pedido) - como ex. fiz de apenas 1 (um). - Na Sessão B: ** Fiz o mesmo SELECT sem a clausula FOR UPDATE: SELECT * FROM tab_material where codg_serma='10' ** aqui eu obtive o resultado ok da leitura. Portanto, é aqui, neste ponto que não deveria permitir nenhuma leitura, já que sessão A ainda não terminou! E AI ALGUÉM PODE ME AJUDAR!? Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com http://www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BLOQUEIO DE REGISTRO
Bom dia Leandro... Concordo com você que seja um tanto quanto decepcionante você não conseguir um lock para consultas, mas como tratado, faz parte do modelo relacional. Também tive essa dificuldade no início, quando vim trabalhar com bancos relacionais. Bem, mas como comentei, uma forma de burlar esta restrição é utilizar a instrução FOR UPDATE NOWAIT. Segue um exemplo: Em uma seção do psql (pgadmin, aplicação da empresa, etc...) aberta eu realizo um select: begin; select * from municipio where cod_uf = 43 FOR UPDATE NOWAIT; (Observe que eu não fechei a transação...) Se em outra seção aberta eu realizar o mesmo select : begin; select * from municipio where cod_uf = 43 FOR UPDATE NOWAIT; O banco simplesmente me retorna a mensagem: ERROR: could not obtain lock on row in relation municipio Bem... É uma forma de burlar o problema a princípio, mas como já discutido aqui, o melhor a fazer (ao menos a médio prazo) é rever a aplicação. Depois de revista, ai sim você pode optar pelo melhor modelo. Utilizar o FOR UPDATE NOWAIT em consultas de atualização não é um erro, mas utilizá-lo indiscriminadamente pode trazer transtornos e efeitos colaterais não desejados. Todavia, como cada caso exige uma solução específica, fica ai a sugestão. Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/12 JotaComm jota.c...@gmail.com Olá, Miguel Faça o seguinte: Sessão A: BEGIN; UPDATE tabela SET codigo=100 WHERE codigo=1; --Vá para a sessão B Sessão B: BEGIN; --Opcional SELECT * FROM tabela WHERE codigo=1; --Aqui você ainda verá o registro 1, porque a transação (Sessão A) que está alterando o registro não fez o commit, então consequentemente você não consegue através desta sessão ver que o registro foi modificado. Para ver que o registro 1 não existe mais é necessário executar o comando COMMIT na Sessão A. Qualquer dúvida pergunta ai. 2009/8/12 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br Bom dia, Leandro, eu concordo com vc, talvez tenho que aprender a conviver com os conceitos de Banco de Dados Relacional e SQL..., mas confesso a vc que para mim é meio decepicionante, não conseguir LOCAR um registro para leitura e poder tratar isso. Até velho bom antigo CLIPPER fazia isso, vc imagina eu acostumado a fazer isso por logos anos, também com ADABAS. Mas eu gostaria, se possível, de lhe perguntar: COMO É POSSÍVEL ATUALIZAR UM SALDO DE QUALQUER COISA (estoque/contacorrente), SEM PRENDER O REGISTRO PARA LEITURA? COMO POSSO SIMULAR ISSO? Obs.: Como algumas pessoas já tentaram me ajudar..., informa mais uma vez que o SELECT ... FOR UPDATE não bloquei leitura! Obrigado! 2009/8/11 Leandro Henrique Pereira Neto leandro-henrique.pere...@serpro.gov.br Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL e DB2). O SELECT simples nunca é bloqueado (somente se usar for update). Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema rapidinho já que somente uma transação poderá ler os dados de cada vez, como em sistema OLTP temos normalmente mais leitura do que alteração a coisa acaba ficando complicada. O que tem são os conceitos de transação e de consistência de leitura. Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não tentar fazer no PostgreSQL o que um banco como o Adabas faz pois estruturas de funcionamento e implementação totalmente diferentes. Leandro Henrique Pereira Neto Administração de bancos de dados Charly Frankl escreveu: Miguel, boa noite... Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem opções, onde para retornar logo que está ocupado utilize NOWAIT. Att, 2009/8/11 JotaComm jota.c...@gmail.com Olá, Miguel Já comentei no email anterior e fiz uma pequena descrição de como isso funciona. Você deu uma olhada no exemplo que mandei? O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita (UPDATE e DELETE). 2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br Oi Mário, Este é o problema a leitura nunca é bloqueada. Fiz os testes pedidos, mas para mim não mudou nada! Veja: - Na sessão 1: db_teste=# BEGIN WORK; BEGIN db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT; LOCK TABLE db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where codg_serma='10'; UPDATE 1 db_teste=# *** aguardando novo comando *** - Na sessão 2: db_teste=# BEGIN WORK; BEGIN db_teste=# SELECT * FROM tab_material where codg_serma='10'; codg_empr | codg_serma | id_serma | desc_serma ---++++--+-- 202 | 10 | 202010 | LAPIS Y| É isso ai!!!?? Obrigado. 2009/8/11 Mário Oshiro mario.osh...@gmail.com Em SQLServer, fiz um teste parecido com
Re: [pgbr-geral] BLOQUEIO DE REGISTRO
Estamos ai pra isso... Precisando, e eu podendo ajudar... [ ]'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/12 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br OI, Charly, Fiz os testes aqui, e é como vc passou. Realmente ajuda! Valeu, Muito Obrigado! 2009/8/12 Charly Frankl carl...@gmail.com Bom dia Leandro... Concordo com você que seja um tanto quanto decepcionante você não conseguir um lock para consultas, mas como tratado, faz parte do modelo relacional. Também tive essa dificuldade no início, quando vim trabalhar com bancos relacionais. Bem, mas como comentei, uma forma de burlar esta restrição é utilizar a instrução FOR UPDATE NOWAIT. Segue um exemplo: Em uma seção do psql (pgadmin, aplicação da empresa, etc...) aberta eu realizo um select: begin; select * from municipio where cod_uf = 43 FOR UPDATE NOWAIT; (Observe que eu não fechei a transação...) Se em outra seção aberta eu realizar o mesmo select : begin; select * from municipio where cod_uf = 43 FOR UPDATE NOWAIT; O banco simplesmente me retorna a mensagem: ERROR: could not obtain lock on row in relation municipio Bem... É uma forma de burlar o problema a princípio, mas como já discutido aqui, o melhor a fazer (ao menos a médio prazo) é rever a aplicação. Depois de revista, ai sim você pode optar pelo melhor modelo. Utilizar o FOR UPDATE NOWAIT em consultas de atualização não é um erro, mas utilizá-lo indiscriminadamente pode trazer transtornos e efeitos colaterais não desejados. Todavia, como cada caso exige uma solução específica, fica ai a sugestão. Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BLOQUEIO DE REGISTRO
É uma alternativa, apesar de eu não gostar muito dela, pois sou a favor da delegação de responsabilidades. Neste caso, transação de banco ser de responsabilidade do banco... Delegando controle transacional para a aplicação podemos incorrer em falhas já corrigidas no banco, além de outros transtornos, como tornar muito complexa a implementação de código, muitas vezes desnecessariamente (e antes que me leve a mal, não estou falando no teu caso, pois nem conheço o problema). Mas como dito anteriormente, e uma das coisas que acho mais bacana na área de TI é que pra cada caso uma solução. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/12 mateusgra mateus...@bol.com.br Resolvi esse problema na aplicação. Em Java por exemplo vc pode fazer um filter onde so vai dar o commit qdo toda a transação for terminada. E se vc for mais alem pode até esperar o subimit do cliente. Seguindo o exemplo da compra online ele so atualizaria o saldo e o estoque se o cliente confirmasse toda a compra. MIGUEL JOSE DE LIMA wrote: Caros, participantes... Sou iniciante neste mundo do PostgreSQL. Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME), mas me incubiram de fazer testes no PostgreSQL para bloquer registros. Então... Estou precisando de ajuda para bloquear a leitura de um registro, ou seja, em um cenário como: Atualização de Estoque de um Material : Antes de atualizar o estoque do material selecionado eu preciso bloquear o registro para que nenhuma outra sessão possa obter o dado do registro. PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE RESTRITIVA. Estou usando o PostgreSQL 8.3.7 para os testes - em linux Já li e reli sobre o Isolamento de Transação, mas pode ser que eu não esteja entendendo...??? Fiz o seguinte teste via psql: - Na Sessão A db_teste=# BEGIN WORK; BEGIN db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT; LOCK TABLE db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE; resultado obtido ok! *** aqui eu preciso bloquear todos os materiais/itens (de um pedido) - como ex. fiz de apenas 1 (um). - Na Sessão B: ** Fiz o mesmo SELECT sem a clausula FOR UPDATE: SELECT * FROM tab_material where codg_serma='10' ** aqui eu obtive o resultado ok da leitura. Portanto, é aqui, neste ponto que não deveria permitir nenhuma leitura, já que sessão A ainda não terminou! E AI ALGUÉM PODE ME AJUDAR!? Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://www.nabble.com/BLOQUEIO-DE-REGISTRO-tp24923152p24937028.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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de índices
Tiago, boa tarde... Apesar de não ser o que perguntou, quero apenas colocar um ponto importante com relação a criação de indices. Todas as vezes que criamos um índice novo em uma entidade, estamos impondo um custo de atualização ao Banco. Pois quando um registro é atualizado (insert/update/delete) os índices também são atualizados. Logo, se você tem uma entidade com muita concorrência transacional, o custo pode ser alto, e o tempo de resposta para atualizações na entidade aumentar consideravelmente. Portanto, a questão de criar ou não índices deve ser vista com muito cuidado, principalmente em entidades que tem uma carga transacional alta. As vezes vale a pena criar um índice temporariamente para uma consulta/relatório específico, e depois de ser realizado o mesmo remover o índice. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/13 Tiago Adami adam...@gmail.com Tenho uma tabela de cadastro de produtos com mais de 20 índices. Qualquer consulta nesta tabela é muito rápida, não importa o que for feito. Entretanto, eu tenho dúvidas quanto ao uso de todos os índices da tabela. Como eu poderia verificar quais os índices mais utilizados ou então quais os não utilizados? Através dos logs do banco? -- Tiago J. Adami Dois Vizinhos - Paraná - Brasil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de índices
Sim... Bem lembrado! Mas como havia falado com relação ao uso indiscriminado, existe a grande possibilidade de um atributo que está sendo atualizado contemplar um índice criado desnecessariamente. O tema índice é muito interessante, e geralmente levanta muitas dúvidas e polêmicas. E como já discutido anteriormente, não existe uma fórmula mágica para o uso de índice. O sistema (estatísticas) vai dizer se precisa ou não. Aplicações com demandas altas de operações transacionais, principalmente inserções e inclusões, costumam (volto a ressaltar, não é regra) demandar uma quantidade menor de índices. Não é raro a situação onde uma entidade muito grande retorna uma consulta com um tempo pequeno, e uma exclusão utilizando os mesmos parâmetros demandam muito tempo para ser realizada em virtude do custo para atualização nas tabelas de índices associadas. Todavia, existem situações diferentes, onde a carga transacional não é tão relevante, mas demanda uma quantidade muito grande de operações de consulta. Nesses casos, obviamente índices bem planejados vão reduzir em muito o custo do banco. E índices bem planejados também incluem utilizar os algoritmos corretos para as classes de operadores corretas... Enfim... O assunto é vasto, e muito interessante, espero termos oportunidades de discutirmos com mais propriedade depois. Um grande abraço a todos! -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/8/13 Euler Taveira de Oliveira eu...@timbira.com Charly Frankl escreveu: Pois quando um registro é atualizado (insert/update/delete) os índices também são atualizados. Vale lembrar que (em uma versão 8.3 ou superior) para o comando UPDATE, isso nem sempre é verdade. O _HOT_ (Heap Only Tuples) foi introduzido justamente para *não* ter que atualizar o índice caso as colunas modificadas não estejam presentes em índices. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Assinatura Digital no Banco
Fábio, boa tarde... Possível é, mas será que vale a pena o custo? Em se tratando de assinatura digital você tem algumas implementações, por exemplo, você pode disponibilizar a assinatura como parte integrante do documento, ou você pode gerar a assinatura em separado e prover um algoritmo/software que valide o documento com base na assinatura. E de forma bem simplista, a assinatura digital nada mais é que um hash gerado a partir do documento e tendo como chave a frase (assinatura/senha/texto/etc) que o usuário cadastrou. Logo se você tem uma tupla de valores, tem a frase e um algoritmo, pode facilmente gerar uma assinatura digital da tupla com base na frase/algoritmo. Ae, você pode mesclar a tupla, gravar em um campo, enfim... fica dependente agora da tua imaginação. Lembrando, que a assinatura digital não vai impedir de o atributo ser alterado por outra pessoa indevidadmente, mesmo porque esse não é o papel dela... todavia, vai te dar a segurança de poder afirmar se o registro foi gravado ou não por um usuário X ou Y. Espero ter ajudado. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/9/10 André Pignata andrepign...@gmail.com Fabio, para fazer isso eu faço o seguinte, para cada usuário na minha tabela de usuário, eu crio o mesmo como usuário do Postgre, logo, qdo que ele é autenticado, ao chamar o comando current_user do BD, eu sei exatamente quem está logado e utilizo essa informação em triggers que me fazem o log. 2009/9/10 Fabio Ebner fabio.eb...@dnasolution.com.br Pessoal alguem sabe se e capaz eu assinar digitalmente um registro do banco??? Exemplo: Tenho na minha empresa 3 funcionarios, cada um vai la e insere via um programa desenvolvido por mim um registro no banco, eu quero saber se tem como ele assinar aquele determinado registro com a assinatura digital dele, ou assinando a informacao ou isso sendo um recurso do proprio banco. Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- André Luiz Martins Pignata Integral Convênios Odontológicos Gerente de TI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Res: Res: Res: Res: Memory (heap)
Bem, acho que o assunto mereça uma thread separada, mas vamos lá. Marcio, boa tarde! Com relação as facilidades do Oracle, eu acho maravilhoso, mas não cabe comparação, pois estamos falando e SGBD... Sistemas (Telas, Relatórios, E-mails e etc...) são ou deveriam ser desenvolvidos utilizando suas tecnologias específicas, tanto que a própria Oracle abandonou e nem sequer presta suporte para os seu maravilhoso Forms/Reports. Em função disso, muitas empresas deram um tiro no pé (a Oracle foi uma delas), ao passo que levaram pra o SGBD rotinas e procedimentos que deveriam ser feitos em outros pontos. Não confunda também, suites que a empresa fornece, ondem vem embarcado o SGBD com o próprio SGBD... São coisas distintas. Agora, com relação a performance, testes, banckmarks, isso tem-se aos milhares mesmo. Ae você me pergunta, qual o melhor? O melhor é o que atende a tua necessidade e o que você domina, além claro, da relação custo. Se você domina extraordinariamente operações com arquivos texto, eles pra você serão muito superiores a qualquer SGBD. Logo, não julgue de imediato um ou outro SGBD em função de outro que você já utilizava antes. Trabalho com Oracle e PostgreSQL, são duas ferramentas extraordinárias, cada uma com suas características e limitações próprias. Vale portanto, se aprofundar um pouco mais em suas respectivas arquiteturas, para perceber onde elas divergem ou convergem, e onde você vai tirar mais ou menos proveito entre um ou outro. Bem, finalizando, e com relação as limitações da Pl/PgSQL, existem muitas sim... algumas facilidades que talvez você tenha em outro SGBD que não vai ter nela... mas tudo isso contornável utilizando-se outras linguagens... Essa é a beleza do PG. Se não suporto ou não possuo tudo em um ponto, criemos mecanismos de extensão para que possamos suprir as deficiências. Aprofunde-se um pouco na arquitetura do PG, e verá que é uma solução extraordinária, com suas limitações claro, e se achar que uma limitação é muito impactante, sugira como melhoria pras próximas versões! Um grande abraço! -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/9/25 MARCIO CASTRO marciomouracas...@yahoo.com.br ÊTA!!! Colega, no mundo Oracle, é comum termos centenas de milhares de linhas escritas em PL/SQL. Esta linguagem é uma das coisas mais legais deste banco. Sua funcionalidade não se restringe a fazer apenas SELECT's, mas aplicações completas utilizando a mesma. Isto significa TELAS (Forms), RELATÓRIOS (Reports), envio de e-mails (DBMS_SMTP), QUEUES (DBMS_AQ) ou CUBOS (DBMS_CUBE), e mais uma infinidade de outras coisas utilizando loops. Recentemente, a Oracle comprou um ERP (E-Business Suíte) formado por mais de 20 milhões de linhas nesta linguagem. Os exemplos que foram passados foram formulados devido à problemas de performance que eu encontrei após passar um pacote especificamente escrito em PL/SQL para PL/pgSQL. Tal pacote é composto de diversas funções e, depois de alguns testes, separei do código o que estava demorando mais: um loop e uma recursividade. Entendeu agora? Munha intenção não é comparar nada, mas resolver um problema de performance no PL/pgSQL. A diferença foi tão absurda que eu achei que tinha um problema na máquina ou na instalação do Post, e então, recorrí à esta lista. Entendido que o problema está na PL/pgSQL, e nada pode ser feito, a conclusão é óbvia: não vou poder fazer isto nesta linguagem, E ACABOU! MAS se o Sr. quiser comparar benchmarks, talvez a saída seja o TPC ( http://www.tpc.org/). Numa olhada rápida, encontrei Sybase, MySQL, DB2, Oracle, EXASOL, SQL Server, ParAccel, Teradata, mas não encontrei nada do Post. OU o senhor mesmo pode me passar, através desta lista, ou diretamente ao meu e-mail, os testes que o senhor julgar significativos, e eu os executarei aquí na empresa. Atenciosamente, Márcio de Figueiredo Moura e Castro ___ 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)
Amigo, acho que não entendeu minha colocação, mas tudo bem... Não estou defendendo um nem atacando o outro, mas com relação a deter 50% do mercado, bem, acho um pouco audacioso por parte da Oracle afirmar isso em um universo onde temos tanta concorrência de qualidade (DB2, Adabas, dentre outros...) Forms/Reports != SGBD ( Oracle Fusion Middleware Application Server ). Hoje roda sobre WebLogic, com uma implementação completamente diferente. O tiro foi tão doloroso que a mesma não o usa em seus projetos (talvez mude.. rsss) !!! E com relação ao arquivo texto, o que eu queria dizer, é que depende mais do profissional/equipe que da tecnologia envolvida pra um projeto dar certo. Logo, se você domina muito bem operações com arquivos texto, talvez você consiga implementar com mais facilidade uma regra complexa de integridade relacional que com um SGBD. Ja vi muitos projetos com ferramentas extraordinárias fracassarem! Com relação a implementação PL/PGSQL == PL/SQL, não sei até que ponto seja interessante, mas nada que nao possamos em um futuro criar uma PL/PGSQL-ORA_EXTEND... :-D Mas, dê uma pesquisada sobre as outras PL's como o pessoal sugeriu, no início pode parecer estranho, mas provavelmente vá se surpreender bastante com o poder e flexibilidade que esse formato oferece. []'s 2009/9/25 MARCIO CASTRO marciomouracas...@yahoo.com.br Colega; a - recordei-me agora de uma palestra da Oracle, no ano de 1999 - sim, já fazem 10 anos - em que arguí um representante da mesma sobre onde eu deveria investir em conhecimentos para o meu futuro como Analista de Sistemas, e o mesmo prontamente me respondeu: em Java; b - não concordo que a Oracle tenha dado um tiro no pé, pois a mesma hoje detém quase 50% do mercado, mas cada um com a sua opinião; c - por favor, você poderia especificar um site de sua confiança com informações de benchmarks do Post? d - arquivo-texto é uma coisa, Sistema Gerenciador de Banco de Dados, é outra, assim como são necessárias 64 regras para que um banco de dados utilize o modelo relacional. Já fui DBA do SQL Server na época do NT (nem dá para contar como eu sofrí), 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; e - a melhoria que eu gostaria é óbvia: o PL/pgSQL igualzinho ao PL/SQL!!! :-) E finalmente: hoje sou DBA, e há muito não acompanho nada sobre o Developer, mas a versão 11g do Forms foi lançada à pouco, no dia primeiro de Julho, para ser mais exato. No dia 31/01/2008, a mesma deixou de oferecer o suporte extendido, mas para a versão 6i! De fato, no site da Oracle, em http://www.oracle.com/technology/products/forms/pdf/10g/ToolsSOD.pdf, encontramos o seguinte: Oracle Forms and Reports Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g. In line with our product strategy, future development activities will be aimed at smoother version-to-version upgrade, integration with features of the platform/ technology stack and product stability. Entendido que o Forms agora faz parte do Oracle Fusion Middleware, procurei em http://www.oracle.com/support/library/brochure/lifetime-support-middleware.pdfmaiores informações sobre o suporte, e encontrei, em Oracle Fusion Middleware Releases, a informação de que o Oracle Fusion Middleware 11gR1 (11.1.1.1.0) terá suporte até Junho de 2017. Então, colega, onde é que você obteve a informação de que a Oracle abandonou e não vai dar mais suporte à esta ferramenta? -- *De:* Charly Frankl carl...@gmail.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Sexta-feira, 25 de Setembro de 2009 12:37:51 *Assunto:* Re: [pgbr-geral] Res: Res: Res: Res: Memory (heap) Bem, acho que o assunto mereça uma thread separada, mas vamos lá. Marcio, boa tarde! Com relação as facilidades do Oracle, eu acho maravilhoso, mas não cabe comparação, pois estamos falando e SGBD... Sistemas (Telas, Relatórios, E-mails e etc...) são ou deveriam ser desenvolvidos utilizando suas tecnologias específicas, tanto que a própria Oracle abandonou e nem sequer presta suporte para os seu maravilhoso Forms/Reports. Em função disso, muitas empresas deram um tiro no pé (a Oracle foi uma delas), ao passo que levaram pra o SGBD rotinas e procedimentos que deveriam ser feitos em outros pontos. Não confunda também, suites que a empresa fornece, ondem vem embarcado o SGBD com o próprio SGBD... São coisas distintas. Agora, com relação a performance, testes, banckmarks, isso tem-se aos milhares mesmo. Ae você me pergunta, qual o melhor? O melhor é o que atende a tua necessidade e o que você domina, além claro, da relação custo. Se você
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Senhores, boa noite... Vou entrar na conversa também. Com relação a índices, sempre é um assunto polêmico, mas muito interessante, e de extrema importância no nosso trabalho. Bem, não conheço a aplicação em questão, logo o que eu falar aqui será com base em conceitos e boas práticas relacionadas a aplicação dos mesmos. Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. Entendam são raros, e não impossíveis. Existem problemas e situações onde isso não se aplique, mas lembrem-se, apenas um dos tantos índices será utilizado na pesquisa. Outro ponto importante, é o índice utilizado... Qual algorítmo? Quais os tipos envolvidos? Com relação a atualização, assim como em uma pesquisa, o uso de índice não é simplório, tendo em vista que o SGBD pode fazer uso de um índice mesmo que o índice não esteja envolvido diretamente na pesquisa (vejam que aumentamos a complexidade aqui!) a atualização também não é simplória ao ponto de o SGBD não tocar em um índice que não esteja envolvido na atualização da entidade. Isso digo não apenas do PostgreSQL, mas do Oracle e DB2. As implicações em termos muitos índices são muitas, e o custo de manutenção dos mesmos devem ser levados em conta sim! Compreendo que aplicações de BI/DW se utilizam de uma técnica não ortodoxa de modelagem, e que muitos conceitos referentes a normalização são de certa forma desprezados em virtude de aumento na performance das pesquisas, até porque não são bases OLTP com auto indice transacional. Logo são aplicações não ortodoxas, que se dão ao direito de não terem preocupações com custos e perdas no momento de atualização. Ainda assim, a grande quantidade de índices não implica diretamente na melhoria da performance das buscas, pois se os mesmos não forem bem planejados, podemos ter índices nunca utilizados ocupando espaço desnecessário, e infringindo uma perda também desnecessária inclusive no momento da pesquisa, pois o otimizador pode, e eventualmente vai, perder tempo em desconsiderar aquele índice como um candidato não eletivo. Lembrem-se, ainda que não utilizado, ele faz parte do dicionário de dados, o qual é utilizado pelo otimizador no momento de decidir qual índice eleger para pesquisa. Bem, finalizando (ainda que querendo falar mais... :-D), podemos perceber que o tema é complexo, e não simplista... Existem muitos pontos e variáveis a serem observadas... Todavia, a minha recomendação é, não extrapolem na utilização de índices, vão infringir uma carga muito grande de trabalho ao SGBD, e aqui indifere o SGBD. Comecem sempre com implementações conservadoras, e a medida que o tempo passar e existirem informações, apliquem as melhorias de tunning e performance necessária. Primem por manter saudável o SGBD, e o excesso de índice pode comprometer a saúde do mesmo! Ah, e antes que me esqueça... Senhores, acalmem-se, estamos aqui para nos ajudar. Não deixemos que a sexta-feira e o cansaço leve para o lado pessoal nossos debates. Eles são muito construtivos, ainda que não concordemos com todos os pontos de vista apresentados. Um grande abraço a todos, e um excelente final de semana! -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/2 Euler Taveira de Oliveira eu...@timbira.com Mozart Hasse escreveu: Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão simplório?! O Oracle e SQL Server por exemplo só tocam num índice se a atualização se referir a campos pertencentes a ele. O PostgreSQL também (vide HOT) mas como *não* sei a que versão se refere preferi afirmar algo conservador... Quanto a inserções (em que pelo menos todos os índices *não condicionais* são atualizados), obviamente elas serão relativamente mais lentas com índices (se você medir com precisão a média em milissegundos), mas isso nem de longe pode ser considerado um problema conceitual Conceito *não*, mas de organização física. Você *não* mostrou essa tal tabela, os índices dela e, o mais importante, as estatísticas de uso desses índices. Posso estar errado (pois não vi a sua estrutura) mas já presenciei vários cenários em que combinei alguns índices e diminuí consideravelmente o número deles sem prejudicar as consultas que os utilizam. Assim, eu consegui aumentar o número de DML/s consideravelmente. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. Como tu farias integridade referencial em um TXT? Não menospreze anos de pesquisa em teoria de SGBDs. Já que você acha que conhece jeitos menos errados de modelar uma tabela que você nem sabe para que serve, nem quantos registros tem, nem a que consultas é submetida, manda lá sua sugestão sobre o que faço para tornar mais rápidas as gravações sem tornar imprestáveis as consultas à minha tabelinha de 89
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Fernando, apenas para não existir erros de interpretação, pois relendo agora a frase eu mesmo demorei a compreender o que escrevi. Faltou pontuação na mesma... rss Com a pontuação adequada ficaria: Concordo com o que o Euler colocou sobre a quantidade excessiva de índices. Uma vez que o SGBD não utiliza mais de um índice por pesquisa, são extremos os casos onde há a necessidade de mais de 5 índices por tabela. []'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/3 Fernando Maia maia...@gmail.com Olá pessoal, eu achu que essa frase responde minha duvida! Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. não é mesmo! ___ 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
De fato, nas versões apartir da 8.2 (se nao me engano) o postgresql consegue simular um indice bitmap em memória, mas como disposto também em [1]: A condição pode ser dividida em n utilizações separadas de um índice sobre uma condição where. Depois é verificado o operador. Depois de os resultados serem recuperados são juntados usando o operador. Para combinar os índices compostos, o sistema percorre cada índice necessário e cria um bitmap em memória, que fornece a localização das tuplas que verificam as condições dos índices. Os bitmaps são então unidos (tendo em conta a interrogação, usando ANDs ou ORs) e as tuplas reais são devolvidas. As tuplas são então visitadas pela ordem física que apresentam, por essa ser a ordem representada pelos bitmap, o que significa que qualquer ordenação do índice original é perdida, e que um passo extra de ordenação irá ser necessário no caso da interrogação incluir uma cláusula ORDER BY. Por esta razão e por ser necessário percorrer o índice um maior número de vezes, o otimizador em geral opta por utilizar um índice simples mesmo tendo outros índices disponíveis. Algumas boas literaturas que podem ser vista sobre o tema são: SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. Editora Makron Books. MOLINA, Hector Garcia; ULLMAN, Jeffrey D.; WIDOM, Jennifer. Database Systems – The complete book. Prentice Hall NAVATHE; ELMASRI. Sistema de Banco de Dados: Fundamentos e Aplicações. Editora LTC [1] http://www.postgresql.org/docs/8.4/static/indexes-bitmap-scans.html Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/5 Fabrízio de Royes Mello fabriziome...@gmail.com 2009/10/5 Euler Taveira de Oliveira eu...@timbira.com Como eu disse anteriormente, o planejador pode produzir um plano que utiliza mais do que um índice por tabela. Por exemplo, em junções com a mesma tabela e quando a tabela aparece em mais de um nó no plano de execução. Tranquilo... isso eu sabia... mas no mesmo nó somente com o bitmapscan para utilizar mais de um índice né? -- 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 ___ 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
Mozart, boa tarde... Acho que não entendeu bem quando eu usei o termo apenas um índice por tabela. Como pode ver, o otimizador notou, pela distribuição dos dados, que compensa usar um índice diferente para cada citação da tabela dentro da mesma consulta (i1tbcidade e a1tbcidade). Como você mesmo colocou, o otimizador optou por usar um índice diferente para *cada citação da tabela* dentro da mesma consulta. Logo, percebe-se que o otimizador trata a mesma entidade como entidades diferente (c e c1). Se você observar, ele optou apenas por um índice para cada entidade sendo: - Index Scan using a1tbcidade on tbcidade c - Bitmap Heap Scan on tbcidade c2 (cost=2.43..28.09 rows=23 width=16) - Bitmap Index Scan on i1tbcidade ou seja, - a1tbcidade para tbcidade c - i1tbcidade para tbcidade c2 Note a diferença nos usos. Não sei se só eu noto isso, mas a maioria das querys com sub-selects ou cláusulas EXISTS que observei na minha aplicação usam índices diferentes para a mesma tabela. Segue aqui o mesmo conceito definido anteriormente. Quando você utiliza uma subconsulta, o otimizador trata de fato como um novo uso para a entidade. Logo, ele pode eleger um índice diferente na consulta interna (tb1) diferente do eleito pra consulta externa (tb1-a ). Logo, no meu caso, ter um monte de índices na mesma tabela compensa sim, e muito. Não creio ser esse o tema do debate, se no teu caso compensa ou não. Mesmo porque, ninguém aqui alem de você pode julgar isso. Agora, voltando ao tema de muitos índices por tabela, como exposto anteriormente pelos colegas Euler e Fabrízio, o PostgreSQL consegue nas novas implementações simular índices bitmap (com seus custos, mas consegue). Inclusive no exemplo que enviou podemos observar o PostgreSQL fazendo uso do recurso, e percebe-se notadamente o que foi exposto na documentação: Recheck Cond: ((uf)::text = 'AC'::text). Agora, com relação a expressão Não sei se só eu noto isso..., desculpe-me se em algum momento meus posts pareceram ser pessoais, muito pelo contrário, apenas tentei colaborar com o debate, mesmo porque é um tema muito interessante. E como falei, todos temos o direito de discordar, errar e acertar dentro dos nossos debates, é isso que torna esta lista construtiva, os erros e acertos de cada um! Um grande abraço, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Alterar constraint ou update com cascade
Marinho, Se entendi o teu problema, você quer um UPDATE CASCADE, certo? Logo, como não tem definido alter constraint, basta remover a antiga e criar uma nova com a sitaxe definida em [1]: ALTER TABLE tbl1 ADD CONSTRAINT fk_tbl1_tbl2 FOREIGN KEY (coluna1) REFERENCES tbl2 ( coluna1 ) ON DELETE casacade ON UPDATE cascade; [1] http://www.postgresql.org/docs/8.4/static/sql-createtable.html Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/5 Marinho Brandao mari...@gmail.com Olá Euler, Não existe ALTER CONSTRAINT. Como eu disse anteriormente você terá que utilizar um bloco de transação contendo ALTER TABLE foo DROP CONSTRAINT e ALTER TABLE foo ADD FOREIGN KEY. veja o que você disse: - dar um UPDATE ... SET ... CASCADE (ou algo semelhante) para atualizar os dependentes simultaneamente Não existe tal sintaxe. - alterar a constraint para ativar o ON UPDATE CASCADE Sim. nesse caso vou fazer como eu sempre fiz e deletar/atualizar/recriar a constraint. obrigado :) -- Marinho Brandão (José Mário) http://marinhobrandao.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como trocar diretório dos bancos j á existentes? Problema URGENTE
Acompanhando o pessoal nos chutes, também creio que exista a variável de ambiente PGDATA já definida em algum ponto (o que não deveria ser problema pois você seta a mesma no arquivo novamente). De qualquer forma, tenta inicializar utilizando o pg_ctl diretamente: postg...@db01:$ pg_ctl -D /sistema/postgresql/data start Outra coisa, verifique no teu arquivo $PGDATA/postgresql.conf se não existem referências para o caminho antigo. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/7 Joao Cosme de Oliveira Junior joao.co...@serpro.gov.br chutaria o teu script de inicialização chamando o seu PGDATA antigo!!! altere para sua nova localização! Em 07/10/2009 às 14:28 horas, pgbr-ge...@listas.postgresql.org.brescreveu: Professor Flávio Brito escreveu: O /var do meu servidor ficou sem espaço e acabei copiando os arquivos do data para um diretório. Troquei o owner dos arquivos e diretório e indiquei dentro do /etc/init.d/postgresql o diretório do PGDATA, mas na hora de carregar ele me manda uma mensagem dizendo que o diretório /var/lib/pgsql não existe (eu troquei o nome) percorri tudo com grep na máquina para ver de onde o tal cara é chamado, mas nada. Estou com a versão 8.2.6 em um RHE4 Dois chutes: (i) existe uma variável de ambiente PGDATA definida no usuário postgres ou (ii) a variável de ambiente PGDATA está definida em /etc/sysconfig/pgsql/postgresql. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ordenando por Where in
Pablo, também não consegui entender o problema. Você pode enviar um exemplo do SQL que você está utilizando? Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/7 Pablo Sánchez phack...@gmail.com Caros. Tenho um problema para resolver, relacionado à uma lib que gera um SQL inválido por ter um order by lá no meio. A questão é que eu consigo ordenar com 2 consultar, em uma coloco o order by, e coloco os ids no where campo in (lista). A consulta funciona então, mas como o where in não traz na ordem em que está em lista, eu precisava saber se vocês conhecem algum jeito de forçar que o banco respeite a ordem dos ids listados em where in. Ex: (129, 23, 1000, 200) e os itens do resultado vierem nessa ordem. Isso tudo só porque atualmente colocaram uma lib velha para caramba, e a mesma dá erro, na versão nova corrigiram a lib, e quebraram outras coisas, mas a questão é que para colocar a nova, eu teria que reescrever quase 70% da aplicação, inviável, então o jeito é resolver com essa solução nada elegante citada acima. Alguma idéia de como forçar a ordenação pela lista do where in? -- = Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 phack...@gmail.com (61) 9975-0883 http://www.sanchez.eti.br http://www.corephp.com.br Quidquid latine dictum sit, altum viditur = ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ordenando por Where in
Uma pergunta para compreender melhor a tua consulta. O atributo l.no_item seria o individuo pelo qual você precisa ordenar? ou não tem nenhum atributo dentro desta pesquisa que determine a ordem, mas sim (apenas) a ordem apresentada no IN ? Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/7 Pablo Sánchez phack...@gmail.com O problema é ter que construir uma query que ordene os elementos pelo resultado de uma outra query. Estou usando uma lib numa versão em que ao usar order by na coluna descritiva do item dá um crash no paginador. Então eu faço uma primeira query, para pegar os ids na ordem que eu preciso, e agora preciso fazer uma segunda query que me retorne os itens listados na ordem que recebi na primeira listagem. O problema é que todas as soluções apresentadas resultaram em uma consulta que retorna tal qual está no banco, ou em sintaxe inválida (o order by in, por exemplo). Query de exemplo. Note que no where in os itens estão fora de ordem, eu preciso que venha nessa ordem aparentemente aleatória (mas é o resultado do order by o nome do item): SELECT l.nu_seq_item_asdf AS l__nu_seq_item_asdf, l.st_possui_recuperacao AS l__st_possui_recuperacao, l.nu_ano AS l__nu_ano, l.no_item_abreviado AS l__no_item_abreviado, l.no_item AS l__no_item, l2.nu_seq_item_asdf_qwer AS l2__nu_seq_item_asdf_qwer, l2.vl_aquisicao_qwer AS l2__vl_aquisicao_qwer, l2.vl_reforma_qwer AS l2__vl_reforma_qwer, l3.nu_seq_item_asdf_municipio AS l3__nu_seq_item_asdf_municipio, l3.vl_aquisicao_municipio AS l3__vl_aquisicao_municipio, l3.vl_reforma_municipio AS l3__vl_reforma_municipio, l4.co_municipio_qwer AS l4__co_municipio_qwer, l4.no_municipio AS l4__no_municipio, l4.sg_uf AS l4__sg_uf FROM qwerqwer.s_item_asdf l LEFT JOIN qwerqwer.s_item_asdf_qwer l2 ON l.nu_seq_item_asdf = l2.nu_seq_item_asdf LEFT JOIN qwerqwer.s_item_asdf_municipio l3 ON l.nu_seq_item_asdf = l3.nu_seq_item_asdf AND l3.co_municipio_qwer = '520870' LEFT JOIN qwerqwer.d_municipio l4 ON l3.co_municipio_qwer = l4.co_municipio_qwer AND l3.co_municipio_qwer = '520870' WHERE l.nu_seq_item_asdf IN (207, 206, 204, 205, 288, 289, 199, 198 ) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Linguagem Procedural
http://www.postgresql.org/docs/8.4/static/xplang.html Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/7 Everson Barbosa everson...@gmail.com Boa tarde pessoal, Alguém sabe onde posso encontrar material sobre linguagem procedural no postgres? Abc Everson ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ter uma tabela com ordem sempre mantida
Rodrigo, boa tarde... Não entendi bem qual o teu problema. Com relação ao algoritmo para a fila de prioridades, você já implementou? A performance foi prejudicada na reorganização dos registros após alteração nos dados? Qual algoritmo/formato de índice você está utilizando? Já tentou utilizar uma tabela em memória? De detalhes do problema, pois ficou um pouco vago. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) 2009/10/26 Rodrigo Sperb rodrigosp...@gmail.com Olá a todos, Eu tenho uma função implementada em PL\PgSQL que itera sempre pegando a linha do topo após ordenar por uma certa coluna. Isso se repete em todas iterações, e como faço atualizações nessa tabela (é uma priority queue, para quem é familiarizado com notação matemática...) no intermédio, não possa ter a ordenação pré-estabelecida e sempre pegar o topo simplesmente... Preciso reordenar sempre. Acontece que isso leva algum tempo e eu preciso melhorar a performance do meu algoritmo. Ele é parte da minha tese de mestrado aqui na Holanda. Meu orientador me comentou que poderíamos ter as posições pré-definidas e fazer atualizações inteligentes, mantendo cada registro na devida posição que deve ocupar... Mas ele ainda não me disse nada de como fazer. Queria, então, saber se alguém tem alguma idéia de como se pode fazer algo assim? Desde já agradeço. Rodrigo Sperb ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF-TOPIC] Porque C ?
Vinicius, bom dia... Como já foi falado aqui, orientação a objetos não é uma vantagem tão grande quando estamos falando de sistemas críticos e necessitamos de performance. Ambas as linguagens tem suas vantagens e desvantagens. A maturidade da linguagem C, incluindo-se aqui suas especificações, além de maior quantidade de documentação e uma comunidade de desenvolvedores muito grande e bem ativa é sem dúvidas um ponto muito forte. Outro fator, que já foi colocado pelos colegas é o custo e risco de reescrever (portar) códigos já existentes em C para C++. Mesmo os exemplos que você utilizou para ilustrar o uso de C++ (Windows, Office) não tem todo o seu código em C++. Por fim, outro ponto preponderante é de fato a performance. Como o Pablo já colocou, toda abstração traz custos. De uma forma bem simplista e digamos grosseira, um objeto nada mais é que um vetor/struct com ponteiros para variáveis (atributos) e funções (métodos) os quais tem mais uma abstração para outra camada de escopo, pois atributos e métodos não podem ser acessados de fora da classe diretamente (sem a necessidade de criação de um objeto), salvo quando os mesmos sejam definidos como estáticos. Dessa forma, tem-se necessidade de mais processamento para tratar tudo isso. Nesse cenário, imagine milhares de instruções sendo executadas e verá que performance é sim um ponto muito importante, principalmente em ambientes críticos. E não cito aqui os micro-dispositivos que possuem pouca capacidade de hardware. Bem, fora isso, tem também o fator gosto pessoal. Pessoas que foram influenciadas de alguma forma por desenvolvedores ou projetos C, certamente vão preferir a linguagem em detrimento de C++. E o contrário também é verdadeiro. Se você começar com C++, vai ver com maior destaque as vantagens desta em detrimento da linguagem C. Bem, e a título de curiosidade, existe SO implementado em Java (bem, não totalmente implementado em Java, pois o mesmo possui um nano kernel escrito em Assembler... rsss) chamado JNode[1]. [1] http://www.jnode.org/ Espero ter contribuído. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) 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. 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 ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Documentação automática (ou q uase) de bando de dados PostgreSQL
O Oracle Data Modeler não é a melhor ferramenta do mercado, mas quebra um galho pra fazer reversa (inclusive do PostgreSQL), e como é desenvolvido em Java roda no nosso bom e velho Linux. Att, Em 20/01/10, Willian Jhonnes L. dos Santos willianjhon...@yahoo.com.br escreveu: Em 20/01/2010 16:40, Welington R. Braga escreveu: Salve todos, Estou precisando documentar um bando de dados em PostgreSQL com centenas de tabelas e que ninguém sabe quem liga a quem e nem há documentação de campos nem nada. Será um trabalho hercúleo e que gostaria de automatizar um pouco pra adiantar. Alguém sabe um programa - preferivelmente para Linux - que consiga me gerar de forma automática um diagrama ER, UML ou algo do gênero? OFFTOPIC Se souberem algum que possa fazer o mesmo com bases MySQL será muito bem-vindo também /OFFTOPIC Grato. Em http://wiki.postgresql.org/wiki/Ferramentas_para_o_PostgreSQL vc encontra algumas referências. GPL tem o Power Archtet ( http://www.sqlpower.ca/page/architect). Caso vc queira uma ferramenta mais robusta, o Power Designer da Sybase faz bem o papel, dando suporte a quase todos os SGBDs existentes no mercado (incluindo o MySQL). -- --- Att.: Willian Jhonnes L. dos Santos Analista/Desenvolvedor Object/Free Pascal willianjhon...@yahoo.com.br --- Seja livre. Use Linux. Grupo de Usuários GNU/Linux de São José dos Pinhais Linux user number 449753 --- Powered by Slackware Linux 12.2 Kernel 2.6.27.8-i686-core2 --- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl Engenheiro de Sistemas http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ 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: Qual o melhor Sistema Operacional?
Uso o Elefante com o bom e velho Debian. Até o momento, parceria perfeita!!! rs Att, -- Charly Frankl Engenheiro de Sistemas http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) 2010/1/21 Marcos André mac.poa...@gmail.com Olá Srs., Estou para criar um servidor de banco de dados PostgreSQL e neste momento nos veio a seguinte dúvida Qual o melhor Sistema Operacional? e para isto estou fazendo um estudo e através da experiencia da comunidade eu preciso saber quais as melhores opções para este tópico. -- At. Marcos André Analista de Sistemas Cel.: (11) 9103-4350 ___ 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: Performance
Senhores, boa tarde... Muito interessante a questão, mas creio que já foi ponderado o suficiente para podermos perceber que tanto Oracle, quanto o PostgreSQL, ou DB2, ou qualquer outro SGBD tem seus pontos fortes e fracos, e devido a isso estarem em constantes evoluções, aperfeiçoamentos e melhorias. É sabido também que todo produto tem seus defensores, desde os mais apaixonados até os menos preocupados. Sem contar o fato de termos clientes que não vão trocar suas arquiteturas legadas pelo simples fato de elas serem pagas (software pago é que é bom), e como sempre estiveram assim, vão permanecer assim até o fim dos tempos. :D Acho que seria mais construtivo para a lista definirmos parâmetros para testes, métodos e boas práticas quanto a procedimentos de armazenamento, pesquisa, modelagem... Ou quem sabe, quando devemos utilizar um índice A ou B... Quais as diferenças de implementação entre um índice Hash e um de Árvore-B, Árvore-R, X/Z/W... Ou então, construir com perguntas do tipo: O SGBD XX tem um recurso interessante que não foi implementado no PostgreSQL, será que teríamos condições de implementá-lo?... Afinal de contas, somos profissionais, e se conhecermos tais pormenores certamente ajudaremos muito na construção deste nosso maravilhoso SGBD. Bem, é apenas uma opnião... Att, -- Charly Frankl Engenheiro de Sistemas http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Instalação
://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- []'s Att. Diego Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seu poder ultrapassa os limites da imaginação - Albert Einstein ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/http://www.midstorm.org/%7Etelles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- []'s Att. Diego Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seu poder ultrapassa os limites da imaginação - Albert Einstein ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl Engenheiro de Sistemas http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Conexão de aplicativos no Postgre
Evandro, Com relação as libs, você verificou se elas estão no path (/usr/lib, por exemplo)? Caso estejam, você pode utilizar o strace para debugar o teu aplicativo e ver de onde ele está tentando carregar as libs. Att, Em 19 de maio de 2010 12:21, Evandro Siqueira vans...@gmail.com escreveu: Aldrey. Em Qua, 2010-05-19 às 12:00 -0300, Aldrey Galindo escreveu: Evamdrp, O erro diz user 'postgre', não errou na digitação não? Obrigado pela ajuda. No Acesso ao Architect o erro era esse mesmo, porem no acesso do lazarus apesar do usuário estar correto o erro permanece. Ele avusa a ausência das libraries. Bem, já tenho 50% do problema resolvido, né? rsrsrs Abraços, Aldrey Galindo Em 19 de maio de 2010 11:29, Evandro Siqueira vans...@gmail.com escreveu: Bom dia Senhores, Instalei recentemente o postgresql 8.4.4.1 em minha máquina e me deparei com a seguinte situação: PGAdmin III - Conecta normal, sem nenhum problema Lazarus c/Zeos - Mensagem: none of the dynamic libraries not found: libpq.so.4, libpq.so Architect c/JDBC - Mensagem: Couldn't connect to database: FATAL: password authentication failed for user postgre Alguém poderia me dar alguma ajuda? Estou tentando migrar do Firebird mas estou parado por falta de conexão com meus aplicativos. Meu ambiente de trabalho é o Linux Ubuntu 10.04, mas tive os mesmos problemas utilizando o Windows XP Ficarei muito grato por qualquer dica que possa ajudar a solucionar o problema. -- Evandro Siqueira. Programador de Sistemas Linna L'essentiel Lingerie Aracaju/SE ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Frankl Engenheiro de Sistemas http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pgbr-dev] Participação da co munidade
Senhores, bom dia! Ao meu ver temos problemas de comunicação, muitas dificuldades de tomadas de decisão e coisas do gênero, mas não creio que unificando as listas consigamos corrigir estes problemas. O problema é estrutural, e como podemos ver pela repercussão desta thread na Geral continuaremos com os mesmos problemas unificando as listas. Sei que cada pessoa tem seus motivos, mas vejo que existe um desinteresse generalizado quando falamos em trabalho para a comunidade, e isso não será resolvido simplesmente unindo duas, três ou quatro listas. Ouço muitas pessoas falando que não participam por desconhecerem a existência da PGBR-DEV, mas no link[1] onde temos o endereço e descrição da lista encontramos ambas as listas. Logo, a alegação de não participar por desconhecimento é no mínimo questionável. Creio que devamos nos preocupar com a renovação da comunidade, pois o curso natural é termos mentes importantes para a comunidade indo embora ao passo que outras venham surgindo. Vejo muitas pessoas surgindo, mas poucas com interesse em participar e sacrificar um pouco do seu tempo para auxiliar no crescimento da comunidade. Com relação a renovação, ou melhor a não renovação, muito do que tem acontecido é em parte culpa nossa, pois nós não damos ou podamos a criatividade de muitas pessoas. Outras vezes, simplesmente não promovemos a participação ou não disseminamos o conhecimento. Algumas idéias simples poderiam melhorar isso, como por exemplo, termos eventos voltados ou com maior inclusão da comunidade acadêmica é algo que sempre traz bons frutos. Outra iniciativa interessante seriam mini-cursos em parcerias com instituições de superiores de ensino a baixo custo, onde disponibilizemos instrutor e a instituição a infraestrutura... Ou seja, existem muitas iniciativas que podemos tomar, mas que vão nos consumir um pouco do nosso precioso tempo... vão nos obrigar a abrir mão de uma parcela da noite ou um dia do convívio de nossa família e coisas do gênero... vão nos exigir um pouco de compromisso com uma comunidade que vem ajudando muitos aqui a crescer profissionalmente. Por fim, deixo um recado ao pessoal da GERAL... Todas as ferramentas aqui apresentadas pelo Telles é aberta a comunidade... não é que vocês podem, mas DEVEM participar das discussões que existem na PGBR-DEV, nos encontros do IRC, que em geral são marcados pela PGBR-DEV... enfim, envolvam-se com a comunidade! Esta é minha opinião. [1] http://www.postgresql.org.br/suporte Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) Em 29 de julho de 2010 10:34, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Senhores, para quem não sabe a comunidade brasileira de PostgreSQL dispões de vários recursos como: Site oficial em http://postgresql.org.br Wiki para organização interna em http://wiki.postgresql.org.br Wiki para artigos em português em http://wiki.postgresql.org/wiki/Portugu%C3%AAs Planeta que agrega blogs com artigos sobre Postgres em http://planeta.postgresql.org.br/ 3 Listas de discução ativas em http://listas.postgresql.org.br/cgi-bin/mailman/listinfo PGBR-GERAL (esta aqui) destinada a dúvidas em geral; PGBR-DEV para organização da comunidade; PGBR-EVENTOS que é um mailing com notícias sobre eventos; Depois do último PGCon Brasil, em 2009, notamos uma queda sensível na participação da comunidade. Até mesmo o PGCon Brasil 2009 passou em branco, com quase nenhuma repercussão, comentários etc. Eu acredito que este é um movimento normal em qualquer comunidade, temos ondas de euforia e momentos de calmaria. É claro que às vésperas do lançamento da versão 9.0, algo realmente empolgante, a comunidade poderia estar em um momento mais vibrante. Mas não está. Como a maioria das pessoas que está nesta lista não acompanha a lista PGBR-DEV (por falta de interesse ou por não saber da sua existência), eu gostaria de pontuar um assunto importante que está rolando lá. A idéia é aposentar a lista PGBR-DEV e passar os assuntos discutidos lá para esta lista. O impacto no volume de mensagens não deve ser muito grande, com a excessão de vésperas de eventos e outras ações organizadas pela comunidade. Tempos atrás estas listas já foram unificadas e em um dado momento (quando todas as listas foram migradas para o nosso servidor próprio) elas se separaram. Eu gostaria de saber a opinião das pessoas sobre da lista PGBR-GERAL, que seriam os principais afetados pela mudança, se ela for aprovada. Não vou manifestar a minha opinião pessoal aqui por enquanto, gostaria de ouvir a opinião das pessoas antes. Então, o que vocês acham? Atenciosamente, Fábio Telles -- blog: http
[pgbr-geral] IV Conferência Brasileira de Postgr eSQL ( portal web )
Pessoal, boa tarde!!! Já estão fechados local e data para o evento este ano 25 a 27 de Novembro na Faculdade de Tecnologia da Universidade de Brasília. Precisamos agora dar continuidade nos trabalhos, e uma tarefa importante é a manutenção do portal web com as informações para o evento deste ano. O responsável por organizar/coordenar esta atualização é o Leonardo Cezar. Sabendo que temos diversos desenvolvedores na comunidade, venho aqui na geral solicitar o apoio de vocês para esta tarefa. Aos colaboradores disponíveis, peço entrem em contato com o Leo e verifiquem com ele as necessidades. Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] quantos campos tem uma tabela?
Lembre-se apenas de levar em consideração o nome do Schema, uma vez que pode-se ter tabelas com o mesmo nome em schemas diferentes. Att, Em 24 de setembro de 2010 04:34, Eloi Ribeiro eloi.ribe...@gmail.comescreveu: OK, já encontrei a resposta, assim: SELECT count(column_name) FROM information_schema.columns WHERE table_name ='nome_da_tabela'; Obrigado, Eloi Ribeiro GIS Analyst 39,45º -4,40º http://eloiribeiro.wordpress.com 2010/9/24 Eloi Ribeiro eloi.ribe...@gmail.com Olá à lista, Existe uma maneira de saber quantos campos tem uma determinada tabela com uma consulta SQL? Obrigado! Saudações, Eloi Ribeiro GIS Analyst 39,45º -4,40º http://eloiribeiro.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tabela Gigante
Em outra mensagem você colocou Não é simples demais para uma tabela que terá milhões de registros ???... O problema não é simplicidade. Na verdade, simplicidade geralmente é a melhor prática! O pessoal aqui falou sobre a tal Chave Natural... mas o que vem a ser uma chave natural?? Durante o processo de modelagem, identificamos atributos ou combinação de atributos que identificam cada ocorrência (registro) como único. Cada uma dessas combinações é conhecida como chave candidata. As chaves candidatas identificam a ocorrência como única, mas precisamos eleger uma delas como chave primária. Vamos pegar como exemplo a provável entidade pessoa_fisica abaixo: create table pessoa_fisica ( id_pessoa cpf nome pai mae ... ) Dentre os atributos acima, podemos eleger como candidatas os atributos id_pessoa e cpf. Cpf, neste caso é a chamada chave natural, visto que a mesma foi introduzida pelo usuário e diz respeito ao negócio, já id_pessoa é uma chave artificial, que é controlada pelo banco e não diz respeito ao negócio, por isso ser artificial. Mas qual a melhor escolha? Existem várias vantagens e desvantagens associadas à essa escolha. Muitas vezes, isso levando-se em conta chaves compostas, chaves artificiais economizam espaço nos índices e nas colunas quando repassadas a FKs e chave naturais costumam economizar em JOINs (se repassamos a chave natural para outras tabelas, talvez não precisemos fazer um JOIN) e principalmente no fato de conter em si uma informação da tupla, ou seja, ela diz exatamente o que é e a que serve. Em todo caso, um dos grandes dilemas entre chaves artificiais e chaves naturais é a volatilidade de tuas regras de negócio. Se você escolhe uma chave natural e hoje a combinação dela é única, o que fazer com o seu modelo de dados se amanhã ela não for unica? Seria muito ruim sair remendando o modelo. Logo, na minha humilde visão, não incluiria os termos certo e errado em se utilizar uma chave natural em detrimento de uma chave artificial, mas sim, ao teu modelo de negócios o que é melhor? Na maioria dos casos, chaves naturais são a melhor escolha, mas como maioria não significa todos, você deve rever teu modelo de negócios e claro, dar uma boa estudada nos conceitos e processos envolvidos em modelagem de dados. Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) Em 28 de outubro de 2010 00:19, Emerson Moretto emore...@gmail.comescreveu: 260.000 é piada para o PostgreSQL, mesmo para realizar buscas. Eu trabalho com um banco com 46 milhões de registros em uma única tabela usando PostgreSQL. Não é o banco principal, é de redundância, mas ele aguenta muito bem, desde que com índices bem feitos. No meu caso: - Desnormalizei tudo, usei tudo em uma única tabela e não faço nenhum join. (sim, repliquei colunas.. campos vazios... etc) - Separei os campos principais de buscas em mais de um campo. E coloquei índice para todos esses campos. Ex: nome_completo - primeiro_nome, ultimo_nome. Então, # select * from tabela where primeiro_nome = 'Jose' and ultimo_nome = 'Silva'; de certa forma, fica como se fosse um like e ao mesmo tempo com muito desempenho. - Criei esses índices de nomes usando o próprio valor do campo no índice. O PostgreSQL por default faz um hash do valor para melhor uso de memória e a comparação. Pra fazer isso: # create index idx_nome on tabela (nome varchar_pattern_ops); Esse varchar_pattern_ops que faz isso acontecer Com isso, a consulta: # SELECT * FROM tabela WHERE nome LIKE 'JOS%' utiliza o índice para fazer o LIKE. Dessa forma, a busca será muito rápida (te garanto, no meu caso ficou em ~25 ms), mas esse LIKE só vai funcionar para quando a busca iniciar com determinado valor. LIKE '%ANA%' ou LIKE '%ANA' vão funcionar, mas fazendo full scan. Enfim, tudo que fiz nesse meu case escrevi nesse post: http://www.emersonmoretto.com/articles/tag/postgres%209 * Não sou especialista em PostgreSQL, apenas admiro, defendo e uso desde a versão 7.2 ** Espero ter ajudado e não ter te confundido mais att Emerson Moretto 2010/10/27 Listas lis...@arsweb.net.br Olá Pessoal, Sou programador em PHP e utiliso o mysql para fazer meus sistemas, bom, estou desenvolvendo um sistema on-line de uma lista telefonica e resolvi usar o postgresql como banco de dados. Porém, estou com dúvidas de como fazer a tabela no banco. A tabela va conter de arrancada 260.000 registros Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep, cidade, estado, anuncio, etc ) Gostaria de saber como criar esta tabela, a estrutura, tipo auto_increment, ja
Re: [pgbr-geral] Res: Res: Res: Escolha do mét odo de replicação
Thiago, boa noite! Talvez uma ferramenta de ETL te seja mais apropriado do que uma ferramenta de replicação. Existem algumas boas ferramentas de ETL disponíveis, e uma que gosto muito é o Kettle[1]. Com ele você consegue fazer extrações agendadas, como você deseja. Dá uma olhada, talvez te resolva o problema. [1] http://kettle.pentaho.com/ Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) Em 28 de outubro de 2010 16:15, Thiago Godoi thiagogodo...@gmail.comescreveu: Obrigado galera , vou pesquisar mais sobre o Slony então, porém ele possui essa opção de replicação agendada dos dados? Por exemplo eu conseguiria definir para ele replicar os dados gerados durante o dia , somente durante a noite? Em 28 de outubro de 2010 16:11, Renato Ricci renatoricc...@yahoo.com.brescreveu: Realmente, concordo com o JotaComm. Provavelmente o Slony seja ideal para sua situação. Com ele você pode escolher quais objetos deseja replicar para o banco slave... T+ __ *Renato R. Ricci* *Antes de imprimir, pense em sua responsabilidade e compromisso com o Meio Ambiente. O Futuro está em Nossas Mãos!*** -- *De:* JotaComm jota.c...@gmail.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Quinta-feira, 28 de Outubro de 2010 15:54:44 *Assunto:* Re: [pgbr-geral] Res: Res: Escolha do método de replicação Olá, Em 28 de outubro de 2010 15:32, Thiago Godoi thiagogodo...@gmail.comescreveu: É realmente já percebi que o hot-standby não é o ideal para a situação. Vou tentar especificar melhor o que desejamos fazer. Tenho um banco de Desenvolvimento onde eu tenho várias bases em que eu estou inserindo novas informações o tempo inteiro.Na máquina de produção a ideia é possuir algumas das bases do banco de Desenvolvimento , somente para consultas de clientes. Hum.. Que tal dar uma olhada no Slony [1] Meu problema seria como levar os dados do meu banco de Desenvolvimento para o banco de Produção (lembrando que seria somente uma parte do cluster), a ideia seria fazer essa atualização todo dia durante a madrugada, é possível algo incremental? [1] http://www.slony.info/ Em 28 de outubro de 2010 14:43, Renato Ricci renatoricc...@yahoo.com.br escreveu: Thiago, deixa eu ver se entendi.. você tem um ambiente de desenvolvimento onde você faz alterações físicas e lógicas no banco de dados. O que você quer fazer é aplicar essas alterações em um banco de produção? O que você vai querer aplicar no banco de produção? Somente o DDL? Ou as informações geradas em desenvolvimento tb? Se você usar um hot-standby, você poderá replicar DDL e informações (cópia fiel do banco) para produção. Não sei como isso impactaria no seu ambiente ai, pois você estará aplicando as alterações no banco de produção mas a aplicação (.exe ou alguma aplicação web) ainda ficará antiga. Se for alterações somente em Functions, triggers, views, ai de boa.. Geralmente as empresas costumam usar um banco hot-standby mais para contingência, ou seja, caso der algum problema no banco de produção, esse banco hot-standby assumiria a brinca. Geralmente tem-se os seguintes ambientes: Desenvolvimento Produção (Processo feito manualmente através de aplicação de scripts com alterações necessárias) Produção (transacional) hot-standby (automático) T+ __ *Renato R. Ricci* *Antes de imprimir, pense em sua responsabilidade e compromisso com o Meio Ambiente. O Futuro está em Nossas Mãos!*** -- *De:* Thiago Godoi thiagogodo...@gmail.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Quinta-feira, 28 de Outubro de 2010 14:25:49 *Assunto:* Re: [pgbr-geral] Res: Escolha do método de replicação Hum creio que usei a palavra errada então, não seria uma replicação. Seria migrar as atualizações para o banco de produção. Porém um detalhe que não havia citado antes, o banco de produção será usado somente para consultas. Em 28 de outubro de 2010 13:40, Renato Ricci renatoricc...@yahoo.com.br escreveu: Thiago, creio que o hot-standby não irá funcionar da maneira que você deseja, pois um banco neste estado não aceita transações pois ele roda somente em read-only. A não ser que você queira usar apenas para consulta. Att., __ *Renato R. Ricci* *Antes de imprimir, pense em sua responsabilidade e compromisso com o Meio Ambiente. O Futuro está em Nossas Mãos!*** -- *De:* Thiago Godoi
Re: [pgbr-geral] Res: Res: Res: Escolha do mét odo de replicação
Thiago, boa noite! Em 29 de outubro de 2010 16:40, Thiago Godoi thiagogodo...@gmail.comescreveu: Charly Obrigado pela sugestão, mas dei uma pesquisada e é uma ferramenta externa ao banco certo? Com isso não estarei perdendo desempenho? De fato, toda ferramenta externa tende a perder um pouco de desempenho, mas como você falou em atualizações agendadas imaginei que essa diferença de performance não fosse ser significativa ao teu modelo de negócio. Além disso o kettle possui algum controle para fazer extrações incrementais ? Como é uma ferramenta de ETL, você pode não apenas criar extrações incrementais, como realizar transformação, adaptação dos dados... Enfim, ela te possibilita uma grande quantidade de possibilidades. Agora, é você dar uma estudada e avaliar se de fato se encaixa na solução que você necessita. Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) Em 29 de outubro de 2010 00:24, Charly Batista carl...@gmail.comescreveu: Thiago, boa noite! Talvez uma ferramenta de ETL te seja mais apropriado do que uma ferramenta de replicação. Existem algumas boas ferramentas de ETL disponíveis, e uma que gosto muito é o Kettle[1]. Com ele você consegue fazer extrações agendadas, como você deseja. Dá uma olhada, talvez te resolva o problema. [1] http://kettle.pentaho.com/ Att, -- Charly Batista Administrador de Banco de Dados http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) Em 28 de outubro de 2010 16:15, Thiago Godoi thiagogodo...@gmail.comescreveu: Obrigado galera , vou pesquisar mais sobre o Slony então, porém ele possui essa opção de replicação agendada dos dados? Por exemplo eu conseguiria definir para ele replicar os dados gerados durante o dia , somente durante a noite? Em 28 de outubro de 2010 16:11, Renato Ricci renatoricc...@yahoo.com.br escreveu: Realmente, concordo com o JotaComm. Provavelmente o Slony seja ideal para sua situação. Com ele você pode escolher quais objetos deseja replicar para o banco slave... T+ __ *Renato R. Ricci* *Antes de imprimir, pense em sua responsabilidade e compromisso com o Meio Ambiente. O Futuro está em Nossas Mãos!*** -- *De:* JotaComm jota.c...@gmail.com *Para:* Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Enviadas:* Quinta-feira, 28 de Outubro de 2010 15:54:44 *Assunto:* Re: [pgbr-geral] Res: Res: Escolha do método de replicação Olá, Em 28 de outubro de 2010 15:32, Thiago Godoi thiagogodo...@gmail.comescreveu: É realmente já percebi que o hot-standby não é o ideal para a situação. Vou tentar especificar melhor o que desejamos fazer. Tenho um banco de Desenvolvimento onde eu tenho várias bases em que eu estou inserindo novas informações o tempo inteiro.Na máquina de produção a ideia é possuir algumas das bases do banco de Desenvolvimento , somente para consultas de clientes. Hum.. Que tal dar uma olhada no Slony [1] Meu problema seria como levar os dados do meu banco de Desenvolvimento para o banco de Produção (lembrando que seria somente uma parte do cluster), a ideia seria fazer essa atualização todo dia durante a madrugada, é possível algo incremental? [1] http://www.slony.info/ Em 28 de outubro de 2010 14:43, Renato Ricci renatoricc...@yahoo.com.br escreveu: Thiago, deixa eu ver se entendi.. você tem um ambiente de desenvolvimento onde você faz alterações físicas e lógicas no banco de dados. O que você quer fazer é aplicar essas alterações em um banco de produção? O que você vai querer aplicar no banco de produção? Somente o DDL? Ou as informações geradas em desenvolvimento tb? Se você usar um hot-standby, você poderá replicar DDL e informações (cópia fiel do banco) para produção. Não sei como isso impactaria no seu ambiente ai, pois você estará aplicando as alterações no banco de produção mas a aplicação (.exe ou alguma aplicação web) ainda ficará antiga. Se for alterações somente em Functions, triggers, views, ai de boa.. Geralmente as empresas costumam usar um banco hot-standby mais para contingência, ou seja, caso der algum problema no banco de produção, esse banco hot-standby assumiria a brinca. Geralmente tem-se os seguintes ambientes: Desenvolvimento Produção (Processo feito manualmente através de
Re: [pgbr-geral] [ajuda]comando copy arquivo csv externo
Rogério, bom dia! mas ao tentar o comando com public.RACA retorna erro novamente -- Executing query: COPY public.RACA FROM '../home/ro/Documentos/base/RACA.csv' CSV HEADER; ERRO: relação public.raca não existe O nome da tabela aparece pra você em maiúscula? Se sim, tente utilizar public.RACA, com o nome da entidade entre aspas e em maiúscula. Att, -- Charly Batista Administrador de Banco de Dados charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [OFF-TOPIC] Surpreendente! Join Microsoft to celebrate Debian 8 at LinuxFest Northwest
Surpreendente: http://openness.microsoft.com/blog/2015/04/21/microsoft-debian-8-linuxfest/ Leia até o fim. Boa sorte. Charly Batista Administrador de Banco de Dados charlyfra...@gmail.com Linux user #391083 Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas idéias. George Bernard Shaw (1856-1950) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [off-topic] Vaga de Emprego
Senhores, boa tarde (ou bom dia ai no Brasil :D) Vou seguir o concelho do amigo Dutra e postar uma vaga aqui na lista. Bem, nao é exatamente sobre PostgreSQL mas para Sys Admin. Gentileza, caso tenham perguntas nao enviem email para a lista. Nao enviem CV para a lista. Enviem para: cha...@letsface.com Segue: Letsface (Shanghai) invites you to join an exciting startup focused on delivering software for events. It helps our customers create amazing events. Guests love it! You will be joining a growing team of engineers; develop, maintain and design our range of products, from simple visual web animation to complex admin backend and API. The ideal candidate will be self-taught, self-directed with a strong sense of initiative, be able to propose ideas, implement them and be able to work under pressure. We offer: - a market competitive salary suited to your abilities and skills, - an international, Silicon Valley-like startup environment with a wide-range of learning opportunities, - a deeply passionate creative, sales and account management team with aggressive targets, - the opportunity to travel in China and internationally for events Desired Skills and Experience Requirements: - Excellent English writing and reading skills, and good English speaking skills, - Be willing to sometimes work extra-hours and work at the site of events when required, - 2-3 years experience in system administration - Bash/Python shell scripting - Cloud computing (Amazon AWS. Rackspace) - Linux (system administration CentOS or Debian) - Nginx, relational databases (especially PostgreSQL) - Virtualization (KVM) - networking commands (dig, ping, traceroute, arp, etc) - network health and services monitoring - security Other stuff we like: - Github (Github Issue tracking, Github API, Github wiki) - Experience using Jira Regards, Charly Batista - Shanghai -China Skype: charlyfrankl E-mail: charlyfra...@gmail.com Linkedin: http://www.linkedin.com/in/charlyfrankl ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
