Re: [pgbr-geral] PostgreSQL com Docker
Opa, vou deixar aqui meus 2 cents. Em 5 de julho de 2017 07:18, Lucas Viecelli 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] 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] 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 : > >> 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] [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 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
[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
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
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 escreveu: > 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 escreveu: > > 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 >> escreveu: >> >> 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 >> > 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 >>>> >>>> *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 >>>> escreveu: >>>> >>>>> É 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, é
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 escreveu: > 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 > 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 >> >> *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 >> escreveu: >> >>> É 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 >> > 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!*** >>>> >>>> >>>> -- >>>
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 escreveu: > 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 > > > > > > > > Olá Pessoal, > > > > Sou programador em PHP e utiliso o mysql para faz
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 escreveu: > 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 > > 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
[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] [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 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
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 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 > > 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] Instalação
t;> >>>>>>>> >>>>>>>> 6643 ?Ss 0:00 postgres: wal writer process >>>>>>>> >>>>>>>> >>>>>>>> 6644 ?Ss 0:00 postgres: autovacuum launcher process >>>>>>>> >>>>>>>> >>>>>>>> 6645 ?Ss 0:00 postgres: stats collector process >>>>>>>> >>>>>>>> >>>>>>>> 7239 pts/1S+ 0:00 grep --color=auto postgres >>>>>>>> >>>>>>>> Preste atenção no parâmetro -D, ele mostra onde está o seu cluster e >>>>>>>> por conseqüência, os seus dados. >>>>>>>> >>>>>>>> Mais que isso, só com o RTFM mesmo. >>>>>>>> >>>>>>>> []s >>>>>>>> Fábio Telles >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >> >> >> -- >> 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] 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] 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é > > 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] 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 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? > > > Se souberem algum que possa fazer o mesmo com bases MySQL será muito > bem-vindo também > > > > 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] [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 > 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] 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 > 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] 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 > 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] 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 > 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] Ordenando por Where in
Como falei, não entendi o teu problema, mas de qualquer forma, você pode manipular o resultado de uma consulta conforme você queira, a maneira mais simples para consultas complexas, é utilizar um SELECT no resultado da tua consulta, como exemplo: select * from ( select 3 as col1 ,2 as col2 ,9 as col3 union select 2,1,1 union select 1,9,4 order by 1 asc ) as t0 union all select * from ( select 9,5,3 union select 4,6,5 union select 6,7,7 order by 1 desc ) as t1 Se você observar, o primeiro grupo de consultas é ordenado de forma contrária ao segundo grupo de consultas. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/7 Pablo Sánchez > Humm... como ficaria esse case? > > ___ 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 > 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] 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 > > 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] 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 > 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] 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] 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 > > 2009/10/5 Euler Taveira de Oliveira > >> 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
Fernando, É por ai mesmo. Na verdade, você pode ter os 50 índices na tua tabela, mas quando for consultá-la o SGBD vai eleger UM índice a ser utilizado para a consulta. Logo, ter 50 índices não é garantia de melhoria na performance da pesquisa, mas alguns índices bem planejados vão com certeza ajudar. Resumindo, a cada consulta o SGBD elege APENAS UM índice da entidade para ser utilizado na consulta. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/5 Fernando Maia > OLá Charly, > Me corrija se estiver errado, de acordo com o que você escreveu não importa > se eu tenho 1 ou 50 indices em uma tabela, pois quando faço uma consulta ao > banco o SGBD utiliza muito poucos indices para realiza-la. > > certo? > > abraços, obrigado pela ajuda. > > 2009/10/5 Charly Frankl > >> 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 >> >> ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Condições em Lowercase e Uppercas e simultaneamente
Stefan, bom dia... Como você não vai fazer uso de índice mesmo ( like '%stefan%' ) pode utilizar as funções upper ou lower no campo nome. Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/5 Rafael Garbin > utiliza o ILIKE > Situação: select * from tabela where nome ilike '%stefan%'; > Acho que isso já resolve seu problema! > > > 2009/10/5 Stefan Horochovec > >> Ola pessoal, bom dia, preciso de uma dica no postgres com relação a >> uppercase e lowercase >> >> Situação: select * from tabela where nome like '%stefan%'; >> >> Porem, se eu tiver cadastrado no banco Stefan ou STEFAN, o banco não >> encontra pelo fato do casesensitive. Como posso flexibilizar isso para que o >> postgres busque em qualquer condição. Em outros bancos, utilizando Collate >> isso resolvia. >> >> Obrigado >> >> Stefan Horochovec >> Engenheiro de Software >> Adobe User Group Manager - FlexDuck >> Blog: http://www.horochovec.com.br/ >> Use Java, Flex e Linux >> >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > Rafael Luís de Souza Garbin > Computer Science Graduate - Software Developer > Skype: rgarbin18 > Msn: garbin...@hotmail.com > Twitter: http://twitter.com/rgarbin > Wordpress: http://rgarbin.wordpress.com > Linux Counter: Registered user #496288 > Phone: 051-97263979 > Grupo Postgres: > http://groups.google.com.br/group/conhecimentos-adquiridos-postgres > .~. >/ v \ > / ( ) \ > ^^-^^ > "Cooperar atrai amigos, competir atrai inimigos " > > ___ > 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
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 > 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
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 > 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 > > qu
Re: [pgbr-geral] Res: Res: Res: Res: Res: Res: Memory (heap)
Marcio, O BEA não é pior que o OAS, pelo contrário, é infinitamente superior, tanto que a Oracle comprou o mesmo! Bem, mas continua não sendo uma tecnologia de banco de dados. Que foi o que eu havia colocado. Mas finalizando, mesmo porque esta discussão filosófica não vai nos levar muito longe, tendo em vista que são duas ferramentas excelentes, o que gostaria que entendesse, e creio que metade da lista, é que as tecnologias citadas não são, digamos assim, de "responsabilidade" do SGBD. Logo, quando falar em "O" Oracle possui toda uma suite, creio não estar correto, pois não é "O" SGBD Oracle, mas "A" Empresa Oracle... São tecnologias distintas... Linguagem, SGBD, ERP, e por ai vai... Assim sendo, uma comparação a esse nível não creio que seja correta. Agora, comparações a nível de banco, como performance, escalabilidade, segurança, etc... são extremamente interessantes, e claro, saudáveis! Afinal de contas, ou somos os melhores e nos preocupamos em manter o posto, ou estamos correndo atras de sermos os melhores... rss :-D Bem, um grande abraço e uma otima noite a todos! -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/9/28 MARCIO CASTRO > Caro Charly: > > Conforme publicado na Computer World, em > http://www.computerworld.com/s/article/9025203/Gartner_gives_Oracle_increased_edge_over_IBM_in_database_market, > em 18 de junho de 2007, a IBM já tinha menos da metade deste mercado, > segundo uma pesquisa do gartner: > > Gartner today *publicly released<http://www.gartner.com/it/page.jsp?id=507466> > * its database market numbers for 2006, saying that worldwide sales > totaled $15.2 billion. Oracle had a 47.1% market share, thanks to $7.2 > billion in database-related revenue, said Gartner, which published a *full > report<http://www.gartner.com/DisplayDocument?ref=g_search&id=507295&subref=simplesearch> > * about the market last Wednesday. > > Oracle's database revenue increased 14.9% year-to-year, and its market > share ticked up from 46.8% in 2005, Gartner said. > > The research and consulting firm gave second-place IBM 21.1% of the market, > with relational database sales of $3.2 billion -- up 8.8% from its sales > level during 2005. But IBM's market share dropped from 22.1% in 2005, and > its revenue increase fell short of the 14.2% growth of the market as a > whole. > > Microsoft > Corp.<http://www.computerworld.com/action/inform.do?command=search&searchTerms=Microsoft+Corporation>remained > in third place with a 17.4% market share last year, according to > Gartner. But the firm said that Microsoft gained ground on IBM, thanks to > year-over-year sales growth of 28% that bumped up its revenue total to $2.7 > billion. > > NCR Corp.'s Teradata division, which is being *spun > off<http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9007555> > * into a separate company, and Sybase > Inc.<http://www.computerworld.com/action/inform.do?command=search&searchTerms=Sybase+Inc.>rounded > out the list of the top five vendors during 2006. But Teradata and > Sybase lagged far behind the three leaders; each had a 3.2% market share, > according to Gartner. > > > Isto pode ser confirmado no próprio site do Gartner, em > http://www.gartner.com/it/page.jsp?id=507466. > > A Information Week também publicou, em 25 de abril de 2008, na URL > http://intelligent-enterprise.informationweek.com/showArticle.jhtml?articleID=207402368, > o seguinte: > > > The relational database market grew 12.1% from $16.6 billion in 2006 to > $18.6 billion in 2007, according to figures released Friday by IDC. Oracle's > relational database revenue grew at 13% to $8.2 billion, giving it 44.1% of > the total market. In 2006, it held 43.7% of the market. > > IBM's revenue grew at a rate of 13.3%, a slightly faster clip than > Oracle's, shoring up IBM's second-place position. It's DB2 and Informix > systems produced $3.95 billion in revenue, or 21.3% of the 2007 market. > > > Em 2008, o percentual da Oracle subiu para 48,9%, mas só conseguí esta > informação da própria Oracle, em > http://www.oracle.com/database/number-one-database.html. > > > Repare que tais relatórios (do Gartner) explicitam quanto estas empresas > estão valendo no segmento "Banco de Dados". > > > Com relação ao BEA (agora virou Oracle Weblogic Server): sempre entendí > que tal aquisição fosse melhor para a Oracle, e que este servidor de > aplicação é muito melhor do que o antigo Oracle Application Server - já > trabalhei com o OAS, e haja saco prá configurar toda aquela tranqieuira - > mas, enfim: > > > Sei que o Forms 11g roda sobre o Weblogic, e não mais sobre o Oracle > Application Server, mas e daí? Qual é o problema em mudar para o BEA? o BEA > é pior do que o OAS? > > > > > > ___ 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 > 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 > *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 v
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 > Ê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] 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 > 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 > >> 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] 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 > 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] 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 > 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] 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 > > 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] 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 > OI, Charly, > Fiz os testes aqui, e é como vc passou. Realmente ajuda! > Valeu, Muito Obrigado! > > > 2009/8/12 Charly Frankl > >> 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
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 > 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 > > 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 >>> >>>> 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). >>>> >>
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 > 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 > >> 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 >> >> 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] 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 > 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 : > > 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 > >> > >> 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 : > >> > Qual a versão do driver vc está utilizando? > >> > > >> > > >> > 2009/8/7 jorge sanfelice > >> >> > >> >> 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 : SELECT veioid,veiplaca > >> >> FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > >> >> logvlogoid = 6 > >> >> duração: 0.137 ms ligação : SELECT veioid,veiplaca FROM > >> >> veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > >> >> logvlogoid = 6 > >> >> duration: 0.182 ms executar : 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] 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 > 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 : > > Qual a versão do driver vc está utilizando? > > > > > > 2009/8/7 jorge sanfelice > >> > >> 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 : SELECT veioid,veiplaca > >> FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > >> logvlogoid = 6 > >> duração: 0.137 ms ligação : SELECT veioid,veiplaca FROM > >> veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > >> logvlogoid = 6 > >> duration: 0.182 ms executar : 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
Qual a versão do driver vc está utilizando? 2009/8/7 jorge sanfelice > 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 : SELECT veioid,veiplaca > FROM veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > logvlogoid = 6 > duração: 0.137 ms ligação : SELECT veioid,veiplaca FROM > veiculo INNER JOIN login_veiculo ON logvveioid = veioid WHERE > logvlogoid = 6 > duration: 0.182 ms executar : 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] 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 > > 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" > Para: "Walter Maier Neto" , "Comunidade PostgreSQL > Brasileira" > 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] 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 > > 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] conceito de trigger
Jorge, Eu não entendi bem tua pergunta. Mas sobre triggers, quando você altera um valor da própria entidade (NEW.campo = novo_valor) você está "reescrevendo" tua instrução de atualização. Neste caso, não irá disparar uma nova chamada, pois não foi disparado uma outra instrução de atualização. Agora se dentro da tua trigger vc tiver um novo INSERT INTO TABLE ou UPDATE TABLE onde as tabelas sejam as mesmas da trigger em questão, creio que pode sim entrar em loop se não tiver um mecanismo para verificar o fim da recursividade. Ae sim, eh um risco. Att, 2009/8/5 Andre Fernandes > Jorge, > Não é uma má prática uma trigger que atualize a mesma tabela à qual ela se > refere. Na realidade, triggers que acabem gerando uma chamada cíclicas > precisam ser evitadas, mas não ocorrem apenas nesses casos. > Diversos sistemas que modelei usam triggers que fazem atualização na mesma > tabela (um exemplo que me lembro muito bem é ter uma coluna date_upd que é > atualizada com o valor now() sempre que tem algum update na tabela.) > > Abraços, > > 2009/8/5 jorge sanfelice > > Prezados estou com uma duvida referente a conceito de funcionamento de >> trigger: >> >>Resumindo, nao é uma boa pratica disparar uma trigger que executa >> uma acao nela mesma, na propria tabela, (posso ta falando besteira, >> mais pode existir a possibilidade de entrar em um laço infinito >> dependendo do "if" que tem dentro da trigger). A idéia correta, seria >> mudar os valores de referencia e retornar um novo array de valores? >> >>Não é uma boa pratica ou esta errado uma trigger executar, um >> update, por exemplo, na propria tabela que dispara esse trigger? >> >>Eu nao faço isso, mais queria saber a opniao de voces antes de >> passar isso aos programadores. Gostaria de saber um conceito exato pra >> nao falar besteira. >> >> Obrigado. >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > > -- > André de Camargo Fernandes > > > > ___ > 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 > 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 > 10<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/>- > Celebridades<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/>- > Música<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/>- > Esportes<http://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] Proposta de estudo sobre definiçã o de índices de BD
ação. > > > A preocupação com índices só vem a tona quando o sistema já está em > operação. > Por quê? Nessa fase, podemos coletar dados (consultas e estatísticas de > índices, por exemplo) para podermos executar as estratégias (i), (ii) e > (iv) > com uma maior eficiência. > > Talvez as estratégias (ii) e (iv) sejam as mais difíceis nesta ordem. > Podemos > ter índices que são 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=grupopesquisa<http://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] 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 > Boa tarde euler, > nao houve mudanca no plano..fui ate 64 de work e nada > > -- > *De:* Euler Taveira de Oliveira > *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 > 10<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/>- > Celebridades<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/>- > Música<http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/>- > Esportes<http://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] 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 > 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] 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 > 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 > > 2009/7/29 Kauí Aires Oliveira : >> > 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] 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
> 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 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
>>
>>> adicionei a propriedade >> /> 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.n
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
> adicionei a propriedade
> 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
>>
