Re: [pgbr-geral] Otimizacao delete
paulo matadr escreveu: Eu to com esse delete na maior tabela do meu banco: A lentidão pode estar associada a alguma chave estrangeira sem índice. Podes fornecer a estrutura das tabela cobranca_documento_item e conta_geral (pk e fk inclusas)? Além disso gostaria de ver um: BEGIN; EXPLAIN ANALYZE DELETE FROM cobranca_documento_item WHERE cnta_id IN (SELECT cnta_id FROM conta_geral WHERE cntg_ichistorico = 3); ROLLBACK; Você está com autovacuum habilitado? Se não, tem executado o ANALYZE periodicamente? -- 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
Re: [pgbr-geral] Indexação com Date
Rafael Domiciano escreveu: Aumentou exponencialmente o custo da consulta, apesar de estar indexida. Não confunda custo com tempo. O custo é uma métrica sem unidade que serve puramente para _estimar_ os planos. Ao analisar um plano você deve comparar o número de registros estimados com número de registros retornados; e, além disso, verificar o tempo gasto em cada nó do plano de execução. Como você *não* apresentou um EXPLAIN ANALYZE fica difícil dizer algo. Percebi que o Postgres não lida muito bem com a performance passando grandes períodos (pode ser que eu esteja errado), não sei como funciona em outros bancos, mas acho isso um pouco falho no Postgres. Como assim *não* tem boa performance? Se a quantidade de dados retornados é grande é claro que ele vai demorar mais tempo. Talvez o que esteja acontecendo é que o PostgreSQL está utilizando o disco (ao invés da memória) para operações de agregação. Se for este o caso talvez você precise aumentar o parâmetro work_mem. No maior período da tabela existem 20 mil registros. Que é uma quantidade tranquila para o 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
Re: [pgbr-geral] Res: Aonde o PG guarda o proximo OID?
Nelson Gonzaga escreveu: Preciso do OID só pra ter um numero que seja unico para usar como indice de uma tabela que ora tem valor ora não tem nada e só depois o valor vai ser digitado. O uso de OIDS em registros de tabelas foi desaconselhado a um bom tempo; *não* aconselho que sua aplicação dependa deles. Por que não utilizar um campo do tipo serial? -- 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
Re: [pgbr-geral] Proposta de estudo sobre definiçã o de índices de BD
Angelo Augusto Frozza (UNIPLAC) escreveu: [Como o amigo Osvaldo costuma dizer: *não* sequestre um assunto, ao invés disso, crie uma nova mensagem; isso bagunça o histórico da lista] Estou iniciando um estudo sobre estratégias para melhor definir índices para um banco de dados. A idéia surgiu como uma pesquisa voltada para um aluno calouro, mas agora passou para um aluno em fase de iniciar o TCC e estou em dúvida na organização da estrutura do trabalho. Inicialmente, tenho percebido em nosso curso pouca preocupação com a modelagem de BD e com a definição correta de índices, sendo que o pessoal limita-se a chave-primária e chave-estrangeira apenas. Nem sempre uma chave estrangeira precisa de índices; tanto é que o PostgreSQL *não* cria índices para chaves estrangeiras. O trabalho, a princípio, foca o estudo exclusivamente para o banco de dados PostgreSQL e nossos objetivos são: - Identificar quais estratégias para definição de índices otimizados são mais utilizadas; - Identificar em que situações cada estratégia é mais indicada; Como assim estratégia? As estratégias que posso visualizar são: (i) criar ou não um índice; (ii) remover um índice; (iii) tipo do índice; (iv) 2 índices em (a) e (b) ou 1 índice em (a, b). Prever quais os índices são necessários na fase de projeto de banco de dados, às vezes, não é uma tarefa fácil (vide a literatura). Por quê? Simplesmente porque é difícil saber se o índice vai ser útil ou não (estratégia (i)). Para saber se um índice vai ser útil temos que conhecer as consultas executadas, a ordem (dezenas, centenas, milhares, ...) da quantidade de registros e até mesmo a seletividade dos dados a serem indexados. Talvez as duas primeiras heurísticas citadas anteriormente sejam as mais utilizadas por DBAs para definir se um índice vai ser criado ou não na fase de projeto; e, mesmo assim pode ser uma suposição errada. No mais, a análise de índices fica para a fase após a implantação. É justamente com o sistema em operação que podem visualizar como a consulta e mudança dos dados estão ocorrendo. - Criar um tutorial, na forma de Wiki, para socializar o estudo sobre a adoção de índices otimizados em bancos de dados livres. Uma dica é colocar isso em [1] ou no espaço brasileiro [2]. A grande dúvida é se existe teoria aplicada sobre a criação de índices durante (ou logo após) a fase de projeto do BD, ou essa preocupação de otimizar os índices é resolvida pela modelagem ou, em último caso, so vai ser interessante mesmo quando o sistema precisar uma análise de otimizaçã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 -- 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
Re: [pgbr-geral] Res: Res: Aonde o PG guarda o proximo OID?
Nelson Gonzaga escreveu:
Usar uma sequencia pra ter um valor temporario não tem graça nenhuma,
vai ficar contando em todo insert e vou usa-lo so em alguns registros e
por algum tempo apenas.
Agora to usando o trigger com current_time, e ta dando certo.
O correto seria utilizar a chave natural de sua tabela.
Sera que o postgresql nao guarda o valor do OID em alguma tabela do sistema?
Você foi avisado sobre o uso dos OIDs. Continuo sem entender porque uma
sequência não atende. Se você precisa que esses OIDs não mudem durante um
cópia de segurança/restauração você precisa especificar o parâmetro (--oids).
euler=# create table foo (a text) with oids;
CREATE TABLE
euler=# insert into foo values('euler');
INSERT 32822 1
euler=# insert into foo values('taveira');
INSERT 32823 1
euler=# select oid, * from foo;
oid |a
---+-
32822 | euler
32823 | taveira
(2 rows)
--
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
Re: [pgbr-geral] Valores de configuração de Perfo rmance
Tiago Adami escreveu: *Não* existe número mágico para sintonia de SGBD. Você precisa entender os parâmetros e conhecer a sua aplicação para adaptar as configurações do PostgreSQL de acordo com isso. Sugiro que leia um material em [1] [2] e [3]. Agora, gostaria de uma validação da comunidade para saber se não estou colocando valores muito fora da realidade. E também saber se existe alguma outra opção que possa impactar na performance para estes hardwares singelos. É difícil saber se está fora sem conhecer a sua aplicação. NOTA: nosso ERP é bem dinâmico, rodando em clientes pequenos (de 1 a 4 clientes simultâneos) até clientes de médio porte (com mais de 60 clientes simultâneos). Portanto a escolha de outro SGBD está fora de questão - como já foi sugerido em outros fóruns. Outro SGBD? Acho que ninguém aqui da lista faria isso. ;) A não ser que você tenha dezenas de milhares de usuários e centenas de milhões de transações por dia. ;) Uma última dica, é homologar e planejar a migração para 8.4. A cada versão temos melhorado a performance e criado mecanismos para entendermos porque o PostgreSQL não está entregando uma performance boa. [1] http://wiki.postgresql.org/wiki/Performance_Optimization [2] http://www.postgresql.org.br/eventos/pgconbr [3] http://www.timbira.com/presentations/pgday_df_2009/perf_pg.pdf -- 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
Re: [pgbr-geral] Sub-Select
Vinicius A. Santos escreveu: Pela demonstração acima pode-se notar que no 8.2 a tabela temporária ficou com o varchar sem especificacao do tamanho e no 8.3 e 8.4 ficou certinho. Estranho, eu realizei o teste agora, apenas com a 8.3. Eu fiz uma visão com o select que eu postei, então fiz o teste no psql com \d nesta visão. O psql retornou o tipo character varying(20). Porém o pgAdmin e a aplicação(em Delphi), o reconhecem como character varying, na mesma base 8.3. Já resolvemos o problema com o cast, mas queria entender o que houve. Eu não entendi porque o tipo importa mas isso é um problema da aplicação (seja ela o PGAdmin ou Delphi) pois o PostgreSQL é capaz de retornar o tipo com o respectivo tamanho (se for o caso). Veja: template1=# select version(); version --- PostgreSQL 8.0.21 on i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) (1 registro) template1=# create table foo (a integer, b varchar(30), c char(10), template1(# d numeric(5,2)); CREATE TABLE template1=# \! cat /tmp/x SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod) FROM pg_catalog.pg_attribute a WHERE a.attrelid = 'foo'::regclass AND a.attnum 0 AND NOT a.attisdropped ORDER BY a.attnum template1=# \i /tmp/x attname | format_type -+--- a | integer b | character varying(30) c | character(10) d | numeric(5,2) (4 registros) -- 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
Re: [pgbr-geral] Sub-Select
Vinicius A. Santos escreveu: Euler Taveira de Oliveira escreveu: Eu não entendi porque o tipo importa mas isso é um problema da aplicação (seja ela o PGAdmin ou Delphi) pois o PostgreSQL é capaz de retornar o tipo com o respectivo tamanho (se for o caso). Veja: Na verdade não importa muito(a não ser pelo trabalho de fazer o cast, e fazer as adequações no Delphi). 'Cast' para que? (Desculpe, eu não entendi ainda...) Eu usei o psql diretamente no servidor(Fedora), para fazer a consulta. Porém se eu conectar pelo meu terminal WinXP, através do pgAdmin, acontece isso, não sei se pode ser a libpq(ou outra DLL), o fato de os 2 aplicativos não conseguirem retornar corretamente. Como eu disse acima, o problema é da aplicação (PGAdmin ou driver utilizado no Delphi); a libpq *não* tem nada a ver com isso. -- 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
Re: [pgbr-geral] Valores de configuração de Perfo rmance
Tiago Adami escreveu: A propósito, não consigo me lembrar direito se existe um aplicativo ou add-on para o pgAdmin que realize métricas para calcular o valor das configurações de acordo com o hardware da máquina e o perfil de uso do SGBD (OLAP, OLTP, desenvolvimento, etc). Alguém tem conhecimento de uma ferramenta que chegue próximo a isso? pgtune [1]. Vale ressaltar que ela *não* faz nenhum tipo de análise dos seus dados e muito menos das estatísticas do seu banco de dados. A idéia dele é justamente montar um postgresql.conf inicial. [1] http://pgfoundry.org/projects/pgtune/ -- 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
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
Re: [pgbr-geral] Sub-Select
Vinicius A. Santos escreveu: tenho um sub-select, que traz um campo de outra tabela do tipo varchar(20). No 8.3 ele retorna o tipo varchar, sem especificar o tamanho, porém no 8.4, ele me retorna varchar(20), como o tipo do campo trazido no sub-select. Isto era um bug do 8.3 ??? vou precisar adequar a aplicação, com cast's explícitos se for o caso. Não entendi... O que tem o tipo? Qual o driver está retornando isso? Não me lembro disso ter sido alterado da 8.3 para 8.4. A informação de tamanho do tipo fica no catálogo (indiretamente -- format_type()). -- 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
Re: [pgbr-geral] Melhorar performance
Sergio Santi escreveu: OK, lá vai. Postgres.conf Parâmetro Padrão ServLentoServRápido max_connections 10070 100 shared_buffers 32MB1000MB 32MB work_mem1MB 64MB 1MB maintenance_work_mem 16MB 256MB 16MB max_fsm_pages 204800 100204800 max_fsm_relations1000 2000 2000 checkpoint_segments 3 310 enable_seqscan on off off enable_tidscan on off off effective_cache_size 128MB 256MB 128MB Consulta usada tanto no ServLento quanto no ServRapido A causa da lentidão é que os planos estão pegando índices diferentes. O índice NotaFiscal_Impressora_Intervencao_Cupom_I escolhido para consulta lenta está com uma estimativa totalmente errada. Os índices NotaFiscal_Impressora_Intervencao_Cupom_I, NotaFiscal_CodigoOperacaoEstoque_I e NotaFiscal_DataEmissao_I estão com estimativas fora da realidade. Você fez um REINDEX neles? Você tentou aumentar o default_statistics_target das colunas que participam do índice para ver se as estimativas melhoram? Além disso, eu *não* aconselharia desabilitar _seqscan_ nem _tidscan_. Mas aconselharia aumentar o effective_cache_size e checkpoint_segments. -- 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
Re: [pgbr-geral] Dúvida em relação à UTF8 e LATIN1
Tiago Adami escreveu: Desculpem a minha ignorância quanto à esta dúvida, mas gostaria de saber o que impacta nos seguintes tópicos quanto ao encoding do banco: - Espaço utilizado (real) em disco; - Ordenação; - Velocidade; - Compatibilidade; O UTF-8 *não* ocupa mais espaço do que o LATIN1 para armazenar o mesmo caractere. A regra de ordenação é a mesma para UTF-8 e LATIN1. Na minha opinião, não há diferença de velocidade significativa. Várias aplicações já conversam em UTF-8 nos dias de hoje. Pergunto porque durante a minha pós-graduação (em Java), recebi informações de um professor que o tipo UTF8 é mais lento e ocupa mais espaço, mas depois de ter aqui neste mesmo fórum - postagem do Euler - a informação de que se não usar Latin1 perde-se a capacidade de ordenação utilizada no Brasil, fiquei com sérias dúvidas à respeito do uso de UTF8 nos bancos. Falar que UTF-8 [1] é lento é mito. Ele só vai ser mais lento se estiver utilizando multibyte [2] (Chinês, Japonês e Coreano são exemplos de línguas que utilizam ele) -- comparado a idiomas latinos armazenados em UTF-8 também. Isso porque os caracteres multibyte precisam de mais bytes para serem armazenados e, então, eles custam mais para serem processados. Eu *NÃO* disse que se perde capacidade de ordenação se _não_ utilizar o LATIN1. Releia o que eu escrevi. Eu disse que *ao utilizar configuração regional C, a ordenação vai ser diferente se você utilizar UTF-8 ou LATIN1*. Hoje utilizamos na empresa e em todos os nossos clientes o LATIN1, sem problemas. Gostaria de algum argumento para justificar o uso do UTF8. A justificativa é justamente que as aplicações hoje em dia conversam em UTF-8. Se a sua aplicação emite caracteres em LATIN1 e o seu banco de dados está em UTF-8, o PostgreSQL terá que converter de LATIN1 para UTF-8 para armazenar e de UTF-8 para LATIN1 para ler os dados. Assim, isso vocês devem decidir como uma estratégia de projeto. [1] http://en.wikipedia.org/wiki/UTF-8 [2] http://en.wikipedia.org/wiki/Variable-width_encoding -- 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
Re: [pgbr-geral] Melhorar performance
Sergio Santi escreveu: Eu imaginava ter enviado as informações solicitadas. Inclusive estava estranhando a demora de uma resposta, mas queria ficar incomodando. Se houver mais alguma informação que eu possa fornecer não exitem em dizer? As informações eu solicitei em [1]. Execute o que está lá e depois publique o que conseguiu. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-July/016610.html -- 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
Re: [pgbr-geral] Res: Analise de uso de index entre 8.2 ou 8.3
paulo matadr escreveu: Segue o explain analyze: O problema é a busca sequencial abaixo. - 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) Ele agregado aos vários laços aninhados (aka _nested loop_) consomem a maior parte do tempo de sua consulta. Além disso, você talvez precise de mais memória (aka work_mem) para executar a consulta. Quais os parâmetros sem comentário no postgresql.conf no servidor de produção? Existe o índice logradouro_bairro_pkey no servidor de produção? As definições das tabelas em ambos servidores são idênticas? -- 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
Re: [pgbr-geral] Migração de PostgreSQL 8.1 par a 8.3/8.4
Tiago Adami escreveu: 2) Provavelmente você criou o cluster na versão 8.3/8.4 como UTF8 ou outro encoding. A partir da 8.3, todos os bancos dentro de um cluster devem possuir o mesmo encoding, então você não conseguirá criar um banco com outra página de códigos. s/A partir da 8.3/Só o 8.3/ O 8.4 permite que você cria bancos de dados com diferentes configurações regionais. Aconselho ler [1] e [2] para entender o que é permitido e o que não é. euler=# create database foo encoding = 'latin1' lc_collate = 'pt_BR.ISO-8859-1' lc_ctype = 'pt_BR.ISO-8859-1' template = template0; CREATE DATABASE euler=# create database bar encoding = 'SQL_ASCII' lc_collate = 'C' lc_ctype = 'C' template = template0; CREATE DATABASE euler=# \l Lista dos bancos de dados Nome| Dono | Codificação |Collation | Ctype | Privilégios de acesso ---+---+-+--+--+--- bar | euler | SQL_ASCII | C| C| euler | euler | UTF8| pt_BR.UTF-8 | pt_BR.UTF-8 | foo | euler | LATIN1 | pt_BR.ISO-8859-1 | pt_BR.ISO-8859-1 | foobar| euler | UTF8| pt_BR.UTF-8 | pt_BR.UTF-8 | postgres | euler | UTF8| pt_BR.UTF-8 | pt_BR.UTF-8 | template0 | euler | UTF8| pt_BR.UTF-8 | pt_BR.UTF-8 | =c/euler : euler=CTc/euler template1 | euler | UTF8| pt_BR.UTF-8 | pt_BR.UTF-8 | =c/euler : euler=CTc/euler (7 rows) [1] http://www.postgresql.org/docs/8.4/static/sql-createdatabase.html [2] http://www.postgresql.org/docs/8.4/static/multibyte.html -- 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
Re: [pgbr-geral] postgresql + cluster + alta disponibilidade
sergio nogueira escreveu: No Rio estamos bastante carentes de cursos sobre estas ferramentas de replicação para PostgreSQL. Fiz pequisas pelo Google e nada ...Só São Paulo ... Você(s) conhece(m) alguma empresa por aqui? O primeiro curso com foco em alta performance e em soluções de alta disponibilidade foi realizado na semana passada por mim em SP. Não conheço empresas de treinamento em PostgreSQL no Rio. -- 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
Re: [pgbr-geral] status da query e coluna Currenty_query completa
Leandro Muller escreveu: [é novo assunto? Não clique em 'Responder' em outro assunto; ao invés disso, crie um novo e-mail. Isso bagunça o histórico da lista.] Com o comando select * from pg_stat_activity posso ver os processos que estão sendo executados, porem preciso exibir a query completa da coluna Currenty_query, existe alguma forma de fazer isso. A partir da 8.4 você pode definir o tamanho máximo de uma consulta em bytes através do parâmetro track_activity_query_size. No entanto, o limite existe justamente porque pg_stat_activity é uma consulta em tempo real; então, se a consulta tem 10 páginas (como algumas que já vi por aí) teremos problemas de performance ao executar uma consulta em pg_stat_activity. Se quiser utilizar numa versão anterior, terá que alterar PGBE_ACTIVITY_SIZE em pgstat.h e recompilar o 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
Re: [pgbr-geral] PG_XLOG aumenta
Walter Maier Neto escreveu: Tenho setado checkpoint_segments = 10, e um partição de 10G para pg_xlog, e hoje o sistema parou pois esta partição completou 100% do espaço em uso e tinha 588 arquivos de log; Você tem certeza que todos esses arquivos eram do log de transação? Geralmente esses arquivos não passam mais do que 2*checkpoint_segments + 1. Acho pouco provável o PostgreSQL *não* apagar esses arquivos, a *não* ser que não esteja fazendo ponto de controle (aka checkpoint). Você tem certeza que checkpoint_segments e checkpoint_timeout _não_ estão muito altos? -- 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
Re: [pgbr-geral] PG em Windows 2008 64 Bits
Saulo Morais Lara escreveu: Pesquisando as mensagens do grupo, vi que mesmo o PG sendo compilado em 32, consigo trabalhar em 64 sem problemas. Estou certo? Obrigado. E? Um histórico [1] diz mais do que mil palavras. ;) [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2008-January/006297.html -- 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
Re: [pgbr-geral] Encoding Latin1 no post8.4 ajuda por favor
fabio.ebner escreveu: Entao Euler o meu problema e com caracteres da lingua portuguesa o WIN1252 aceita todas as acentuacoes ??? ç õ ó è ñ ï ö ( no caso de nomes estrangueiros) etc.??? Você leu a minha resposta? Latin-1 (aka ISO 8859-1 -- sem o hífen) é um padrão ISO. Ele é a base (subconjunto) das codificações consolidadas ISO-8859-1 (com hífen) e Windows-1252. Portanto, Latin-1 *não* é tecnicamente o mesmo que Windows-1252; eles são compatíveis mas existem caracteres (códigos de controle) no Windows-1252 que não estão presentes no Latin-1. Para confirmar olhe em [1] e [2]. Eu não uso Windows, mas o comando abaixo deve funcionar para você: CREATE DATABASE seu_bd WITH ENCODING 'WIN1252' LC_COLLATE='Portuguese_Brazilian.WIN1252' LC_CTYPE='Portuguese_Brazilian.WIN1252' TEMPLATE=template0; [1] http://en.wikipedia.org/wiki/Windows-1252 [2] http://en.wikipedia.org/wiki/ISO-8859-1 -- 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
Re: [pgbr-geral] erro: cache lookup failed for relation
jorge sanfelice escreveu: O que gera esse select é um aplicativo em C, a funcao que é chamada dento do arquivo C é em pltcl. Logo, voce esta sugerindo que eu fique dropando e criando a funcao em tcl a cada 5 min (no caso antes de executa-la) ? Sim. Só pra ficar mais claro, esse select, busca o nome de algumas views e de uma tabela temporaria. (c.relname ilike '%sincroniza_view' ). Esse é o problema. O plano faz cache do OID da tabela temporária e na próxima execução ele _não_ encontrar a tabela temporária. -- 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
Re: [pgbr-geral] pgbench
Marcelo Gomes escreveu: Fiquei sem entender... esses valores que o pgbench retorna é melhor que seja maior ou menor ??? Imaginava que quanto maior melhor, mas o hardware do meu note é inferior aos dos servidores e deu uma diferença grande para mais. Sem algumas informações sobre o seu hardware, versão do PostgreSQL e configurações do mesmo e configuração do pgpool, fica difícil dizer algo. Eu recomendaria a utilização do pgbouncer para os testes também. Qual o fator de escala utilizado? *Não* é recomendável utilizar um fator de escala menor do que o número de cliente para os testes. Além disso, vale lembrar que a execução de qualquer outro serviço nas máquinas pode influenciar nos resultados do seu teste. No caso de utilização de um _pool_ em uma máquina separada, certifique-se que a rede não é um gargalo. -- 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
Re: [pgbr-geral] Banco finaliza com select
Alisson Viegas escreveu: Ao executar o select abaixo o banco de dados finaliza o serviço. Testei e o problema está na função to_ascii. Notei que se usar a mesma função em outro campo funciona. O que é finalizar o serviço? Qual o *erro* apresentado? É mais fácil apresentar o erro do que ficar tentando descrevê-lo. Qual a versão do PostgreSQL? SO? Qual a codificação de caracteres utilizada? Suponho que seja uma versão 8.2 ou menor e você inseriu alguns caracteres inválidos no campo que está tentando fazer a consulta. -- 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
Re: [pgbr-geral] erro: cache lookup failed for relation
jorge sanfelice escreveu:
Se ajudar, o erro se da nesse momento:
Error: cache lookup failed for relation 251674995
COMMAND: SELECT c.relname, n.nspname FROM pg_catalog.pg_class c JOIN
pg_catalog.pg_roles r ON r.oid = c.relowner LEFT JOIN
pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN
('v','r') AND n.nspname NOT IN ('pg_catalog', 'pg_toast') AND
pg_catalog.pg_table_is_visible(c.oid) AND c.relname ilike
'%sincroniza_view' ORDER BY 2;
Acho muito pouco provável o problema estar nesta consulta. São somente tabelas
do catálogo e não temporárias.
Você já experimentou carregar a sua função em C (aka DROP FUNCTION e CREATE
FUNCTION) antes de invocá-la periodicamente?
--
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
Re: [pgbr-geral] RES: Banco finaliza com select
Alisson Viegas escreveu: Não é apresentado nenhum erro. O serviço PostGres no Windows é finalizado e não retorna a consulta. Tentei executá-la no pgAdmin e aparece * Erro *, simplesmente. Cenário: Win2008 64bits PostGres 8.3.1 UFT-8 Argh...O psql vai te mostrar o erro. -- 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
Re: [pgbr-geral] Exportar Select
Lucas Souza escreveu: 2009/7/16 Marcelo Cardoso de Souza marceloc...@gmail.com mailto:marceloc...@gmail.com Olá a todos, Alguem saberia me dizer se é possivel exportar os resultados de um select para arquivo txt com os campos separados por ';' e delimitador por ''. Oi marcelo, Sim, É possível o que você quer é exportar o resultado de uma consulta SQL para CSV (valor separado por virgula), ontem implementei isto em um aplicativo :) mas você pode fazer o mesmo pelo PGAdmim... (tela consulta / arquivo - exportar...) Faltou dizer que o comando por trás da cena é o COPY [1]. euler=# copy pgbench_branches to '/tmp/foo' csv delimiter ';'; COPY 5 euler=# \q $ cat /tmp/foo 2;41658; 3;-91276; 5;-26113; 1;65433; 4;15198; [1] http://www.postgresql.org/docs/8.4/static/sql-copy.html -- 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
Re: [pgbr-geral] Exportar Select
Lucas Souza escreveu: Na verdade não disse, porque desconhecia* o Comando COPY [1], mas o Marcelo Costa, respondeu o que faltou dizer :) A minha idéia foi _só_ complementar a sua resposta. Quem estiver procurando o mesmo assunto no histórico verá mais de uma opção para o que procura. -- 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
Re: [pgbr-geral] Postgis 1.3.6 no Postgresql 8.4
Leonardo Euler Santos escreveu: Tenho uma dúvida e gostaria de contar com o apoio da lista. Tentei instalar o Postgis 1.3.6 na minha máquina e não consegui. O erro informado foi que eu deveria ter o postgresql instalado, entretanto é lógico que já tenho o postgresql instalado e a versão que estou utilizando é a 8.4. Como eu disse em um outro assunto mais cedo, *não* tente descrever o seu erro, apenas poste o comando juntamente com o erro. Pode acreditar que isso é mais fácil para os outros colegas visualizarem a solução para o seu problema. -- 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
Re: [pgbr-geral] Encoding Latin1 no post8.4 ajuda por favor
Osvaldo Kussama escreveu: Creio que o correspondente ao LATIN1 no MS-Windows é o WIN1252. (quem trabalha com MS-Windows: favor confirmar) Latin-1 (aka ISO 8859-1 -- sem o hífen) é um padrão ISO. Ele é a base (subconjunto) das codificações consolidadas ISO-8859-1 (com hífen) e Windows-1252. Portanto, Latin-1 *não* é tecnicamente o mesmo que Windows-1252; eles são compatíveis mas existem caracteres (códigos de controle) no Windows-1252 que não estão presentes no Latin-1. Considerando que aplicações não emitirão caracteres de controle (^H aka backspace, ^I aka tabulação, ...) podemos dizer que eles são a mesma coisa. -- 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
Re: [pgbr-geral] Melhorar performance
Mozart Hasse escreveu: [é meio off-topic ao assunto inicial mas...] No meu caso o que sempre fez e continua fazendo uma falta desgraçada no Postgres é um otimizador decente. Bem que se podia aproveitar a idéia aplicada no Oracle ou no SQL Server e ter um cache de planos, reduzindo o número de compilações. Esse tempo hoje é relativamente pequeno (e insuficiente) no Postgres, exatamente porque ele precisa fazer isso a cada consulta. Se puder gastar mais tempo e aproveitar esse processamento (como o Oracle e o SQL Server fazem faz tempo), talvez ele se torne viável para mais aplicações. Isso já existe: chama-se comandos preparados (aka _prepared statements_). É claro que você precisa manter a conexão mas nada que um aglomerador de conexões (aka _pool_) não resolva. Como você mesmo disse, o tempo é relativamente pequeno em aplicações Web e OLTP; em OLAP, algumas consultas com dezenas de junções esse tempo é significativo (aumenta 2^n mas é para isso que temos o GEQO) mas mesmo assim bem inferior ao de execução da consulta. Outra coisa que ajudaria bastante seria a coleta de estatísticas mais detalhadas para uso do otimizador, como dados sobre correlação entre valores de campos dentro da mesma tabela (como o Oracle e o SQL Server fazem faz tempo). Isso obviamente consome um tempo, porém nem se compara com o desperdício que o Postgres faz com as estimativas furadas dele. É fácil falar do otimizador mas é difícil mexer nele. ;) Já tivemos essa discussão a um tempo atrás mas em minha opinião, eu não importo se o número de registros indicados na estimativa seja muito diferente dos números reais (afinal de contas, é uma *estimativa*!); o que me incomodaria é se por essa estimativa ser bem diferente do real, eu tenha um plano de execução que não é o ideal. Se eu me lembro bem, nenhuma das consultas apresentadas por você produzia um plano que não era ideal. -- 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
Re: [pgbr-geral] Buscar palavras em qualquer ordem
..:: Rodrigo (-_-) Machado ::.. escreveu:
Resumindo, tem q trazer todos os registros que contenham uma e outra
palavra.
Qual é a melhor pratica para isto?
Como você mesmo disse: busca textual (aka _text search_). Veja:
euler=# create table foo (a tsvector);
CREATE TABLE
euler=# insert into foo values('Euler Taveira de Oliveira'),('Jose Taveira dos
Santos'),('Joao Tavares da Cunha');
INSERT 0 3
euler=# create index fooi on foo using gin (a);
CREATE INDEX
euler=# select * from foo where a @@ 'Taveira Oliveira'; -- operador E
a
---
'Euler' 'Oliveira' 'Taveira' 'de'
(1 row)
euler=# select * from foo where a @@ 'Taveira | Oliveira'; -- operador OU
a
---
'Euler' 'Oliveira' 'Taveira' 'de'
'Jose' 'Santos' 'Taveira' 'dos'
(2 rows)
--
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
Re: [pgbr-geral] Problema com trigger
Ivan Wilhelm escreveu: create trigger servicoDataAtualizacao after update on servico for each ^^^ É claro que ele não vai alterar. Ali deve ser _before_ porque se você dispara o gatilho *após* a atualização as alterações no registro NEW *não* farão efeito algum. -- 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
Re: [pgbr-geral] logging
sergio nogueira escreveu: como faço para ter no arquivo apontado em log_directory/log_filename um log debug5 mas, no prompt do psql, tenha apenas notice? O que você procura é client_min_messages (cliente) e log_min_messages (log) [1]. É necessário habilitar a coleta de logs (logging_collector) para segunda opção funcionar. [1] http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN -- 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
Re: [pgbr-geral] PGLOG, pg_log
sergio nogueira escreveu: mais algumas dúvidas (enquanto leio o manual): a que se refere a variável de ambiente PGLOG? Existe a variável pg_log? Onde você viu isso? O PostgreSQL só utiliza as variáveis definidas em [1]. PGLOG é o nome da variável utilizada em scripts de inicialização e *não* é uma variável conhecida pelas aplicações que utilizam a libpq. Já abusando ... e PGLIB, LIBDIR, libdir? Poderiam acrescentar algum comentário? (Devo acrescentá-las todas ao profile do postgres?) Para que? As únicas variáveis de ambiente que tu podes definir (e que o PostgreSQL vai enxergar) estão em [1]. [1] http://www.postgresql.org/docs/8.4/static/libpq-envars.html -- 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
Re: [pgbr-geral] logging
sergio nogueira escreveu: log_min_messages = debug5 ... Para que tu quer utilizar debug5? Isso *só* é recomendável para desenvolvedores. Em um ambiente normal, isso vai gerar *tanto* log que vai atrapalhar o desempenho do próprio PostgreSQL. Reiniciei o servidor: pg_ctl stop e no pg_ctl start, o susto : corte Eu quero estas e todas as outras mensagens no arquivo e não tela. Tem como? Aproveitando, se voce puder fazer algum comentário sobre as variáveis de ambiente que postei num e-mail anterior, também lhe ficaria muito grato. Essas mensagens aparecem porque o _logger_ (processo que gerencia os logs do PostgreSQL) não foi iniciado ainda. Se você não utilizar debug*, ou seja, no mínimo _info_ essa mensagens não aparecerão. Se mesmo assim quiser usar o debug*, ignore os dados da saída padrão ao iniciar: $ pg_ctl start -D $PGDATA 1/dev/null -- 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
Re: [pgbr-geral] PGLOG, pg_log
sergio nogueira escreveu: Quanto ao PGLOG, está em monte de lugares (menos nos manuais). Por exemplo, neste artigo da SQLMAGAZINE (link abaixo). Mas veja bem, são curiosidades. Eu só queria o significado delas ... O Google tá cheio de PGLOG O que não está no manual do PostgreSQL *não* existe. ;) Falando sério, o PostgreSQL documenta *tudo*. É uma política do grupo de desenvolvimento que para um patch ser aceito ele tem que conter a documentação necessária. O que não está documentado é porque (i) não existe, (ii) vai ser mudado futuramente (vide por exemplo SQL/MED) ou (iii) os desenvolvedores não querem expor detalhes ao usuário comum. -- 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
Re: [pgbr-geral] logging
sergio nogueira escreveu: Mas a questão não é essa ... tive a impressão que se podia ter um nível de mensagem no cliente e outro no arquivo. Não consegui. Achei essa configuração extremamente complicada. Mas esta configuração existe. Como eu disse no e-mail anterior, client_min_messages e log_min_messages controlam as mensagens enviadas ao cliente e ao log, respectivamente. Eu não acho que isso é inflexível e complicado. Redirecionar para /dev/null foi o que eu passei a fazer, na primeira vez. Mas é chato. E as mensagens para o cliente acima do nível de notice, de qualquer forma, continuam aparecendo. Estes tipos de mensagens (debugs), aliás, talvez nunca devessem ser enviadas ao cliente (pgsql). Há alguma justificativa para isso? Por que não? Tem mensagens que identificam a transação que estão disponíveis somente com um nível mais alto de log. Além disso, você pode depurar no cliente e não no servidor (isto é o que eu chamo de ter flexibilidade). O que vai para /dev/null são somente mensagens na inicialização do postgres que na maioria das vezes não são significativas para depurar (a não ser que você tenha mexido na rotina de inicialização); depois que o logger é iniciado, tudo começa a ir para o arquivo de log. -- 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
Re: [pgbr-geral] Agradecimento pela ajuda para especificar um SAN
Welington R. Braga escreveu: Após algumas semanas lendo e relendo vários manuais e testando configurações, o equipamento já está funcionando com 8 discos de 750GB em RAID50, totalizando 4.5TB de espaço e conectado à um servidor com CentOS 5.2. Por que RAID 5+0? E não o 1+0? Você fez teste com ambos? -- 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
Re: [pgbr-geral] Dúvida Sinataxe Trigger
Osvaldo Kussama escreveu: CREATE FUNCTION verifica_6_partidas() RETURNS trigger AS $$ DECLARE TOTAL_JOGOS_ANDAMENTO int; BEGIN SELECT COUNT(*) INTO TOTAL_JOGOS_ANDAMENTO FROM Partida WHERE Fim IS NULL AND (Jogador1 = NEW.Jogador1 OR Jogador2 = NEW.Jogador2); IF (TOTAL_JOGOS_ANDAMENTO = 6) THEN RAISE EXCEPTION 'O jogador possui 6 partidas em andamento. Não foi possível prosseguir esta operação!'; END IF; RETURN NEW; ^ END; $$ LANGUAGE plpgsql; -- 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
Re: [pgbr-geral] Dúvida Sinataxe Trigger
Leonardo Barbosa escreveu: ERROR: column NEW.Jogador1 does not exist NEW.Jogador1 -- 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
Re: [pgbr-geral] max_fsm_pages
sergio nogueira escreveu: Então, perdoe a minha falta de conhecimentos mais básicos se algum conhecimento ou raciocínio básico for exigido para resposta, dado determinado volume previsto para uma tabela, como estimo tal valor? Se você der um chute muito alto vai precisar de mais memória compartilhada. Como suas manutenções são regulares (eu espero que sejam), esses valores _não_ vão precisar ficar sendo alterados toda hora. Basta fazer um ciclo de manutenção (de um dia para o outro?) e executar um VACUUM VERBOSE para prever o quanto esse valor deve ser. Em caso de um chute errado, poderia haver corrupção de dados, ao se executar o vacuum? Não, _free space map_ não tem nada haver com manipulação de dados (assim é impossível que um bug em seu algoritmo cause algum dano aos dados); além disso, ele está obsoleto (ou seja, é auto-configurável) a partir do 8.4. -- 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
Re: [pgbr-geral] Forca o uso do index
paulo matadr escreveu: Existe alguma forma no postgres de forca o uso de um indice particular, do tipo eu tenho 3 indices semelhantes e a,b e c. eu queria que apenas o C fosse usado pra uma query especifica. Lembro que no oracle,usa-se hints.E no nosso querido postgres ? O planejador geralmente faz a coisa certa; não tente ser mais experto do que ele. É claro, que há casos em que ele não é experto o suficiente. Então, se o PostgreSQL não escolheu o índice que você queria é porque (i) ele julgou que o índice escolhido é aquele que contém um custo menor ou (ii) o seu julgamento estava errado. Sem olhar um EXPLAIN ANALYZE e a estrutura das tabelas e índices envolvidos na consulta fica difícil dizer algo. É como o Fábio disse, _hints_ são _gambiarras_ para quem *não* quer corrigir o planejador. Além disso, eles podem dar um certo poder de julgamento (às vezes, errado -- caso clássico é utilizar _indexscan_ ao invés de _seqscan_ em que a consulta precisa varrer toda ou quase toda tabela) para o desenvolvedor. O PostgreSQL prefere melhorar o planejador do que adicionar gambiarras para escolha de outros planos de execução. Por fim, se você tem índices semelhantes é muito provável que você não precise de algum deles. -- 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
Re: [pgbr-geral] Erro ao configurar o Slony.
charles andre escreveu: Estou tentando rodar um script para criação de uma replica com slony, o script funciona perfeitamente na maquina de teste mas em produção gera o seguinte erro: As versões são as mesmas? Habilite o log de consultas para ver qual é a consulta que está causando isso. O banco esta ok aceita conexoes etc. Não estou querendo reiniciar o banco não sei se ele esta corrompido. Pode ser que esteja com dados corrompidos ou alguma função do Slony está derrubando o _backend_. A versão do Slony é 1.2.10 Postgresql 8.2.4 FreeBSD 6.2 Slony já está na 1.2.16 e 2.0.2; sugiro que utilize pelo menos a 1.2.16. O PostgreSQL já está na 8.2.13 e 8.4.0; sugiro que utilize pelo menos a 8.2.13. -- 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
Re: [pgbr-geral] Proibir a criação de objetos
Aluisio Gouveia escreveu: É possível permitir que um usuário conecte no banco e acesse objetos que ele tem permissão, mas proibir a criação de novos objestos, se sim, como fazer? Geralmente é só revogar os privilégios do usuário no esquema onde estão os seus objetos. Veja: euler=# create role foo login; CREATE ROLE euler=# create table bar (a int); CREATE TABLE euler=# revoke create on schema public from public; REVOKE euler=# \c - foo psql (8.4.0) Você está conectado ao banco de dados euler agora como usuário foo. euler= create table teste (a int); ERRO: permissão negada para esquema public euler= insert into bar values(2); ERRO: permissão negada para relação bar euler= \c - euler psql (8.4.0) Você está conectado ao banco de dados euler agora como usuário euler. euler=# grant select,insert on bar to foo; GRANT euler=# \c - foo psql (8.4.0) Você está conectado ao banco de dados euler agora como usuário foo. euler= insert into bar values(2); INSERT 0 1 euler= delete from bar; ERRO: permissão negada para relação bar euler= \z Privilégios de acesso Esquema | Nome | Tipo | Privilégios de acesso | Column access privileges -+--+---+---+-- public | bar | table | euler=arwdDxt/euler | : foo=ar/euler (1 row) -- 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
Re: [pgbr-geral] ENCODING - Latin-1 e UTF-8
Roberto Mello escreveu: Não entendo Luiz. A meu ver o UTF8 tem mais vantagens, mais padronização, e mais proteção contra o futuro, em relação ao LATIN1, que nem tem todos os caracteres que precisamos, como o símbolo do Euro, por exemplo. Além do que o Roberto disse, não ter que onerar o servidor PostgreSQL com conversões entre codificações e não ter que se preocupar com falha de conversões são alguns dos motivos a favor do UTF-8. Se boa parte da pilha de serviços utiliza UTF-8, o uso dele no banco de dados é recomendável. E o LATIN1 ainda tem codificações diferentes em sistemas diferentes. ISO-8859-1 e ISO 8859-1 são codificações DIFERENTES e o Windows tem ainda uma versão diferentes de um deles, não lembro qual. Windows-1252. -- 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
Re: [pgbr-geral] Saber de onde veio o disparo da trigger
Anderson Aguilar Ferreira escreveu: Eu sei sim o conceito de TRIGGER. [...] E o que eu queria nao e qual operacao ativou a trigger e sim de onde ela foi ativada. E ja sabia que isto nao tem no PostgreSQL, mas nao custa nada perguntar. A ativação (disparo) sempre vem de uma *tabela* (como eu disse na resposta anterior). O que não tem no PostgreSQL? É sabido que o mesmo implementa somente um subconjunto do que o padrão especifica mas certamente é suficiente para a maioria dos casos. E antes de responder da maneira que vc respondeu, entenda primeira a pergunta, Sr. Sabe Tudo. Eu não quis te ofender em nenhum momento. Só disse que se você entendesse o conceito de gatilhos saberia que eles são _disparados_ de acordo com uma ação na tabela (e não em uma restrição -- *constraint*). Por que os brasileiros sempre levam as coisas pelo lado pessoal [1]? Em nenhum momento eu disse que _sabia tudo_; só tentei te dar o caminho das pedras mas se você entendeu de outra maneira... [1] http://www.timbira.com/presentations/pgconbr_2008/falando_elefantes.pdf -- 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
Re: [pgbr-geral] alter table ... set tablespace
sergio nogueira escreveu: talvez o comando abaixo não exiba o nome de tablespaces default de banco (o que seria, talvez, estranho). Exato, se é padrão ele não aparece, ou seja, a tabela atual *não* está em uma _tablespace_. Veja: euler=# create table foo (a int); CREATE TABLE euler=# select tablename,tablespace from pg_tables where tablename='foo'; tablename | tablespace ---+ foo | (1 row) euler=# \! ls /tmp/foo PG_VERSION euler=# alter table foo set tablespace footbs; ALTER TABLE euler=# select tablename,tablespace from pg_tables where tablename='foo'; tablename | tablespace ---+ foo | footbs (1 row) euler=# -- 16384 é o banco de dados 'euler' euler=# \! ls /tmp/foo/16384 16410 euler=# select relfilenode,relname from pg_class where relname ~ 'foo'; relfilenode | relname -+- 16410 | foo (1 row) euler=# alter table foo set tablespace pg_default; ALTER TABLE euler=# select tablename,tablespace from pg_tables where tablename='foo'; tablename | tablespace ---+ foo | (1 row) euler=# -- 16410 é um arquivo vazio que será removido quando for conveniente euler=# \! ls -l /tmp/foo/16384 total 0 -rw--- 1 euler users 0 Jun 22 01:26 16410 euler=# select relfilenode,relname from pg_class where relname ~ 'foo'; relfilenode | relname -+- 16411 | foo (1 row) -- 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
Re: [pgbr-geral] alter table ... set tablespace
sergio nogueira escreveu: Em que tablespace está a tabela? Funciona aqui. Qual versão? psql (8.4beta2) Digite help para ajuda. euler=# \! mkdir /tmp/foo euler=# create tablespace footbs location '/tmp/foo'; CREATE TABLESPACE euler=# create table foo (a int); CREATE TABLE euler=# insert into foo select generate_series(1, 10); INSERT 0 10 euler=# select tablename,tablespace from pg_tables where tablename='foo'; tablename | tablespace ---+ foo | (1 row) euler=# alter table foo set tablespace footbs; ALTER TABLE euler=# select tablename,tablespace from pg_tables where tablename='foo'; tablename | tablespace ---+ foo | footbs (1 row) -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu:
Criei Indices parciais, aumentei o _sharedbuffers_ e mesmo assim o desempenho
não ficou bom.
O problema é que ele gasta muito tempo lendo páginas do índice para memória;
e, como você *não* tem um _shared buffer_ suficiente para armazenar essas
páginas, há muitas trocas. Essa tabela sofre muitas atualizações durante o
dia? O autovacuum está habilitado?
Você poderia tentar executar o comando CLUSTER pelo índice bari (e verificar
se o tempo gasto no IndexScan diminui).
Além disso, você poderia mostrar as estatísticas da tabela bar utilizando:
euler=# \x
Exibição expandida está habilitada.
euler=# select * from pg_stats where schemaname = 'public' and tablename =
'bar';
-[ RECORD 1 ]-+-
schemaname| public
tablename | bar
attname | a
null_frac | 0
avg_width | 13
n_distinct| 2
most_common_vals | {jorge vilela,euler taveira de oliveira}
most_common_freqs | {0.998004,0.00199601}
histogram_bounds |
correlation | 1
--
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
Re: [pgbr-geral] FATAL: terminating connection due to administrator command
[Lexxis] Alexandre Biancuzzi escreveu: Estou com problema com conexão com banco postgre. *PostgreSQL* ou simplesmente *Postgres*. Nunca *postgre* ou *postgree*. Aleatoriamente retorna a seguinte mensagem: FATAL: terminating connection due to administrator command Isso é porque alguém (administrador?) parou o serviço do PostgreSQL. Vide mensagem logo abaixo. LOG: shutting down LOG: database system is shut down corte LOG: received fast shutdown request LOG: aborting any active transactions E como é um desligamento rápido, ele aborta todas as transações atuais. -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: explain analyze select * from bar where a ~ '^MARIA DAS.*GRACAS' LIMIT 10; QUERY PLAN Limit (cost=0.00..22.86 rows=1 width=62) (actual time=115.751..468760.019 rows=10 loops=1) - Index Scan using bari on bar (cost=0.00..22.86 rows=1 width=62) (actual time=115.739..468759.911 rows=10 loops=1) Index Cond: (((a)::text ~=~ 'MARIA DAS'::character varying) AND ((a)::text ~~ 'MARIA DAT'::character varying)) Filter: ((a)::text ~ '^MARIA DAS.*GRACAS'::text) Total runtime: 468760.159 ms (5 rows) O plano de execução é esse mesmo mas estou imaginando o porquê do tempo excessivo de processamento no Limit. Qual o tamanho desta tabela _bar_ e do índice _bari_? Qual a versão do PostgreSQL e SO? Qual o tamanho do seu _shared buffers_? Esse índice foi criado recentemente? Se não foi, um REINDEX diminui o tempo de processamento? -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: Postgresql 8.2.7, FreeBSD 7.1 ^^^ Sugiro atualizar para 8.2.13; vários bugs foram corrigidos e, você não precisa mexer nos dados, ou seja, é necessário apenas atualizar os binários. tabela bar = 14GB Indice bari = 7264 MB shared_buffers =512MB ^^^ Aha. Por que o valor do _shared buffers_ está tão baixo? Quanto de memória tem disponível? É um servidor dedicado ao 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: Pelo que li na documentação o ideal é usar 1/3 da ram para o shared_buffers. É um servidor dedicado ao postgresql e tem 4GB de ram com 200 conexoes simultaneas. Não tem isso de ideal (é uma maneira didática que usamos para aconselhar usuários com menos experiência ;). Eu não conheço a sua aplicação, mas utilizar apenas 8% da memória para _shared buffers_ (quando se tem consultas que utilizam mais do que isso -- 7GB só um índice!), *não* é o ideal. Meu chute inicial seria pelo menos 768 MB ou mesmo 1GB. Mas para ser mais preciso é necessário saber mais sobre o seu ambiente tais como tamanho dos objetos e frequência de uso deles (aka pg_stat*). E mais, dependendo do tamanho da sua base e se o uso desse índice for algo frequente, eu recomendo que compre mais memória para a máquina. -- 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
Re: [pgbr-geral] Postgres 8.2.13 em Windows 64bits (Urgente)
Raphael Garcia escreveu: Um amigo comentou que também teve problema com Windows 64 bits e não conseguiu instalar (aí ele optou pelo Ubuntu). Verifique se a versão do PostGreSQL é para Win 64, pois se for para Win 32 não vai funcionar. *Não* existe PostgreSQL compilado para 64 bits ainda. Todas as versões para Windows (inclusive a 8.4) são compiladas para 32 bits mas funcionam _perfeitamente_ em máquinas com Windows 64 bits. Não há previsão mas algumas pessoas estão trabalhando nisso [1]. [1] http://archives.postgresql.org/pgsql-hackers/2009-06/msg00873.php -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: Se tiver 70 mil variações de Euler Taveira demora bastante para lista os 10 primeiros. Qual o EXPLAIN ANALYZE da consulta? -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: Gostaria de saber se o Tsearch tem como localizar um texto que comece com uma determinada palavra com se fosse o like 'POSTGRESQL 8.2%'. Você _não_ entendeu o conceito de busca textual [1] (aka text _search_); quando se transforma um texto no tipo tsvector, este perde posicionamento e ganha peso (relevância) e proximidade. Assim, sem posicionamento é impossível fazer uma comparação com prefixo do texto. O uso do :* nos deixa comparar com o prefixo de *cada* lexema. O que você precisa é de expressões regulares [2]. Veja: euler=# create table bar (a text); CREATE TABLE euler=# insert into bar select 'euler taveira de oliveira' from generate_series(1, 10); INSERT 0 10 euler=# insert into bar select 'jorge vilela' from generate_series(1, 5000); INSERT 0 5000 euler=# create index bari on bar (a text_pattern_ops); CREATE INDEX euler=# select * from bar where a ~ '^euler'; a --- euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira (10 rows) euler=# explain analyze select * from bar where a ~ '^euler'; QUERY PLAN - Bitmap Heap Scan on bar (cost=4.35..25.17 rows=10 width=13) (actual time=0.101..0.224 rows=10.00 loops=1.00) Filter: (a ~ '^euler'::text) - Bitmap Index Scan on bari (cost=0.00..4.35 rows=10 width=0) (actual time=0.055..0.055 rows=10.00 loops=1.00) Index Cond: ((a ~=~ 'euler'::text) AND (a ~~ 'eules'::text)) Total runtime: 0.334 ms (5 rows) [1] http://www.postgresql.org/docs/8.4/static/textsearch.html [2] http://www.postgresql.org/docs/8.4/static/functions-matching.html#FUNCTIONS-POSIX-REGEXP -- 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
Re: [pgbr-geral] TSearch palavar Inicial
Jorge Vilela escreveu: Aqui eu já estou utilizando a versão 8.4 (Justamente por esse motivo), Eu *não* aconselharia utilizar a 8.4 ainda. Podem vir a aparecer bugs que precisam mudar o formato dos arquivos de dados (é claro que essa possibilidade é baixa já que estamos lançando a RC1 mas...). O Euler apresentou o :* como coringa para término ou começo de string, mas eu não consigo utilizá-lo em ambos os casos. Veja: Você *não* entendeu o que o :* faz [1]. O curinga :* permite fazer uma busca pelo prefixo mas *não* pelo sufixo (ainda). Afinal de contas, quem vai pesquisar no Google por 'tor' para obter 'monitor'? [1] http://www.postgresql.org/docs/8.4/static/datatype-textsearch.html#DATATYPE-TSQUERY -- 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
Re: [pgbr-geral] postgresql 8.4
Leandro Müller escreveu: [Pare de sequestrar os assuntos; se é um assunto _novo_ *não* clique em responder e apague o conteúdo da mensagem, ao invés disse crie uma mensagem nova. Isso _bagunça_ o histórico da lista.] Alguém leu algum artigo sobre desempenho na versão 8.4, das novidades, teste comparativos com a versão 8.3? O único teste que vi sobre o desempenho do 8.4 foram [1][2]. Quanto as novidades, temos a palestra [3] do Robert no PGCon e a da Fernando Ike [4] (que acontecerá daqui 2 semanas no FISL). Temos uma matriz [5] que mostra a evolução das funcionalidades no PostgreSQL comparado com as versões anteriores. [1] http://www.kaltenbrunner.cc/blog/index.php?/archives/26-Benchmarking-8.4-Chapter-1Read-Only-workloads.html [2] http://www.pgcon.org/2009/schedule/events/124.en.html [3] http://www.pgcon.org/2009/schedule/events/179.en.html [4] http://fisl.softwarelivre.org/10/papers/pub/ [5] http://www.postgresql.org/about/featurematrix -- 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
Re: [pgbr-geral] TSearch palavar Inicial
mateusgra escreveu: E se eu quiser pesquisar que comece com Euler e termine com oliveira. Indice com _pattern_ops so aceita pesquisa no inicio do campo. A documentação é o seu melhor amigo. Você testou o que mandei? É claro que ele usa o índice; só não vai utilizar se você fizer uma pesquisa com sufixo. euler=# select * from bar where a ~ '^euler.*oliveira'; a --- euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira euler taveira de oliveira (10 rows) euler=# explain analyze select * from bar where a ~ '^euler.*oliveira'; QUERY PLAN - Bitmap Heap Scan on bar (cost=4.35..25.17 rows=10 width=13) (actual time=0.123..0.448 rows=10.00 loops=1.00) Filter: (a ~ '^euler.*oliveira'::text) - Bitmap Index Scan on bari (cost=0.00..4.35 rows=10 width=0) (actual time=0.054..0.054 rows=10.00 loops=1.00) Index Cond: ((a ~=~ 'euler'::text) AND (a ~~ 'eules'::text)) Total runtime: 0.562 ms (5 rows) E indice gist não aceita indice composto. Quem falou em índice GiST? É um B-Tree mesmo. Não consegui resolver esse problema ? Faltou ler as referências que enviei. :( Se você não conhece o poder das funcionalidades do PostgreSQL fica difícil você saber se algo se encaixa na sua solução. -- 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
Re: [pgbr-geral] Dúvidas/idéias sobre pool de cone xões com pgbouncer
Fabrízio de Royes Mello escreveu: O DISCARD ALL [3], conforme documentação, executa os seguintes comandos na ordem que segue: - SET SESSION AUTHORIZATION DEFAULT; - RESET ALL; - DEALLOCATE ALL; - CLOSE ALL; - UNLISTEN *; - SELECT pg_advisory_unlock_all(); - DISCARD PLANS; - DISCARD TEMP; Destes comandos não consegui implementar o DISCARD PLANS (se alguém souber como faço isso, e se é possível, eu agradeço). Esse comando veio em conjunto com a funcionalidade de invalidação de planos em funções procedurais. Então, ele *não* pode ser emulado em versões 8.3. Com base nisso tenho uma dúvida (até mais desconfiança que dúvida mesmo) que tenho é relacionada a essa PL que implementei (em anexo), pois configurei ela no parâmetro server_reset_query, assim como o pgbouncer [2] indica pra fazer com o DISCARD ALL, e apesar de estar em testes com resultados positivos há algum tempo em nosso ambiente de desenvolvimento ainda tenho receio de colocar em produção. Se a sua versão do PostgreSQL mais velha é a 8.2 (sem ela tu não vai conseguir emular a maioria dos comandos do DISCARD ALL), tu podes substituir a primeira consulta por: select setting from pg_settings where name ~ 'server_version_num' Além disso, a melhor maneira de excluir as tabelas temporárias não é excluindo o seu esquema [fazendo alguns testes...] pois ele vai reutilizar o OID do esquema temporário para as tabelas temporárias subsequentes (um bug do pg?). Ao invés disso, remova as tabelas uma a uma (é como o DISCARD TEMP faz). A documentação do pgbouncer não é grande coisa, por isso estou aqui cheio de receios... será que estou indo pelo caminho certo ou existe algum outro porém nessa estória??? Ou será que o mais seguro é aguardar e utilizar o pgbouncer somente em conjunto do PostgreSQL 8.3??? A versão 8.3 te daria mais segurança mas se você alterar o que disse acima acho que vai funcionar com 8.2. Eu faria um teste de unidade (?) para saber se a função proposta está se comportando de maneira correta. -- 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
Re: [pgbr-geral] Criacao tabelas
paulo matadr escreveu: Pessoal, alguem tem uma ideia de como agente guarda ou onde ta guardado a data de criação de uma tabela? A menos que tu habilite (parâmetro log_statement com valores ddl, mod ou all) no postgresql.conf, o PostgreSQL não guarda tal informação. -- 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
Re: [pgbr-geral] LDAP - Como se autenticar? - pg_hba.conf
Juliano escreveu: Alguém poderia me ajudar, por gentileza, me dizendo como autenticar usando o método ldap no pg_hba.conf? Não precisa ficar repetindo a pergunta. Você já procurou no histórico da lista [1]? Esse assunto já foi discutido a um tempo atrás. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2008-July/010614.html -- 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
Re: [pgbr-geral] Postgres 8.2.13 em Windows 64bits (Urgente)
Ezequiel Gonzaga escreveu: Preciso fazer o postgres funcionar em Windows 2008 64bits. Mas quando estou instalando no finalzinho ele dá um erro e não instala, o que deve estar acontecendo??? Sem a mensagem de erro é _quase_ impossível dizer algo. Além disso, porque está utilizando a versão 8.2 se a 8.3 já foi lançada a mais de 1 ano e a 8.4 está saindo do forno? -- 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
Re: [pgbr-geral] Como verificar se o serviço do PG e stá ativo no windows
Wilson Angeli escreveu: Como faço então, para verificar se o banco(PG 8.3) está ativo no windos(XP,2003/2008 server)? Tem várias maneiras: pg_ctl status -D c:\my\pgdata psql -c select 1 -U user mybd utilizando a saída do netstat. -- 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
Re: [pgbr-geral] Teoria de SGBD - Compilador de Consulta / Compilador DML
lokoder escreveu: Os materiais que consultei mostram um compilador de consulta e um compilador DML na arquitetura do SGBD. O compilador de consulta entraria em cena quando fazemos uma consulta ad-hoc, usando o terminal, por exemplo, e o compilador DML quando embutimos um comando SQL de consulta num software. Acho que você confundiu as coisas. No PostgreSQL (vide [1]), temos dois módulos: DML (execução de consultas tais como SELECT, UPDATE e DELETE) e DDL + outros (consultas tais como CREATE TABLE, GRANT e TRUNCATE). A minha dúvida é: por que dois compiladores pra 'mesma coisa'? Porque simplesmente o primeiro módulo (DML) precisa montar um plano de execução e o segundo módulo *não*. Claro que elas chegarão ao SGBD por diferentes modos, mas estando lá dentro, não significam a mesma coisa, a nível de compilação/otimização? Errado. Elas chegam pelo mesmo modo; e, após passar pelo _parser_ elas vão para um caminho ou para outro (slide 18 em [1]). [1] http://www.timbira.com/presentations/pgday_df_2009/perf_pg.pdf -- 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
Re: [pgbr-geral] Teoria de SGBD - Compilador de Consulta / Compilador DML
Euler Taveira de Oliveira escreveu: Acho que você confundiu as coisas. No PostgreSQL (vide [1]), temos dois módulos: DML (execução de consultas tais como SELECT, UPDATE e DELETE) e DDL + outros (consultas tais como CREATE TABLE, GRANT e TRUNCATE). ^^ comandos. -- 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
Re: [pgbr-geral] PostgresSQL em português no UBUNTU!
Hotmail - Fabrício Fachini escreveu: O locale do UBUNTU esta configurado para PT_BR, o parâmetro LC_MESSAGES também; os arquivos .MO (por exemplo, psql.mo) foram criados, Configurar o parâmetro lc_messages do postgresql.conf? -- 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
Re: [pgbr-geral] Como interpretar o custo de uma consulta
Ricardo Neves escreveu: A pergunta é a seguinte: Para que eu saiba o custo total da consulta, devo somar todas as etapas do custo? Pelos testes que realizei os valores de custo são apresentados por etapas. Qual é a forma correta de interpretar os dados, visto que o gerenciador apresenta duas estatísticas de custo para cada etapa? Envio um exemplo para análise: A métrica da esquerda é do modelo de custo utilizada pelo PostgreSQL e a da direita o tempo de execução _real_ gasto para executar aquele nó. Os custos vão sendo somados de baixo para cima e de acordo com a identação. Além disso, ele te mostra informações sobre o número de registros retornados por nó (o número real é o da direita; o da esquerda foi o número (estimado) utilizado para produzir o plano). O número de _loops_ sugere quantas vezes foi executado aquele passo. No mais, sugiro ler [1] e as referências apresentadas lá (principalmente 'Explaining Explain' e 'Introduction to VACUUM, ANALYZE, EXPLAIN, and COUNT'). [1] http://wiki.postgresql.org/wiki/Using_EXPLAIN -- 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] modo digest
Olá, Gente, não é querendo ser chato mas já sendo... Esta é a segunda mensagem _digest_ que vem para a lista esta semana. Vamos respeitar as regras da listas e *não* enviar mensagens _digest_ para a lista. Por quê? (i) bagunça o histórico da lista. Quem vai saber o que é Digest pgbr-geral, volume 28, assunto 5? (ii) vem com todos os assuntos discutidos que são irrelevantes para a discussão (caso o OP não corte -- o que muitos clientes como o gmail evitam); (iii) dependendo do dia temos um e-mail com tamanho considerável. Em resumo, _digest_ é só para aqueles que querem *somente* ler os assuntos. Se quiserem responder algo, tem como dizer para o Mailman (gerenciador de listas) enviar para você aquele e-mail específico, então você pode respondê-lo (particularmente acho muito trabalhoso). Se quiserem participar das discussões *não* utilizem o modo _digest_. -- 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
Re: [pgbr-geral] Recuperação de dados.
Pedro B. Alves escreveu: Fiz a instalação do postgresql-8.2.. a mesma que estava anteriormente, o banco inicia tranquilamente, só que quando tento acessar o banco de dados do sistema ele diz que um diretório 17875 não existe dentro do diretório pg_tblspc da pasta data, alguém saberia como faço para achar/recuperar este diretório? O que a consulta abaixo retorna? Você vai precisar olhar o spclocation (/tmp/foo) correspondente ao oid (47458). euler=# select oid,* from pg_tablespace ; oid | spcname | spcowner | spclocation | spcacl ---++--+-+ 1663 | pg_default | 10 | | 1664 | pg_global | 10 | | 47458 | footbs | 10 | /tmp/foo| Depois disso é copiar os dados para o mesmo diretório (/tmp/foo) e fazer um link simbólico em $PGDATA/pg_tblspc. No Windows seria assim: cd c:\my\pgdata\pg_tblspc mklink 47458 c:\my\tablespace\dir -- 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
Re: [pgbr-geral] Modificar tamanho máximo dos arquiv os de dados
Fabiano Chiqueti escreveu: Há possibilidade de diminuir o tamanho máximo desses arquivos? Isso ajudaria na performance de updates em tabelas grandes? Você não especificou qual o tipo de UPDATE mas estou supondo que seria um com uma cláusula WHERE. Neste caso, *não* vejo como estaria aumentando a performance de um UPDATE pois o PostgreSQL (i) escreveria os dados no WAL, (ii) os dados ficariam armazenados nos _shared buffers_ até que (iii) um checkpoint escreva esses dados no disco (neste caso ele alteraria tudo em um arquivo e usuaria somente um fsync -- que é a parte cara). A operação (iii) é a mais cara delas (mas se você configurou adequadamente os parâmetros de _checkpoint_); ela só vai ser executada minutos depois do comando UPDATE ser retornado. Portanto, ela não influenciaria _diretamente_ na performance do UPDATE. -- 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
Re: [pgbr-geral] Versão 8.2.7
Nilson Chagas escreveu: Estou procurando esta versão (8.2.7), para que posso desenvolver o projeto com a mesma versão que esta no host. Você pode encontrá-la em [1]. Mas eu utilizaria a última versão da série 8.2 (atualmente 8.2.13) pois ela contém uma série de correções. Nada é adicionado ou removido entre a versão 8.2.x e 8.2.y; somente bugs são corrigidos. Eu também sugeriria o _host_ a atualizar a versão pois *não* é necessário um _dump_/_restore_; somente atualização dos binários. [1] ftp://ftp-archives.postgresql.org/pub/source/v8.2.7/ -- 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
Re: [pgbr-geral] listar tabelas pelo tamanho
Leandro Cavalari Soares escreveu: Tenho duas que são úteis pra minha aplicação onde listo os TOP 10 (índices e tabelas), mas são separadas: * ÍNDICES: o SELECT relname AS indice, pg_size_pretty(relpages*8192) as tamanho FROM pg_class JOIN pg_indexes ON relname = indexname ORDER BY relpages DESC limit 10; * TABELAS: o SELECT relname AS tabela, pg_size_pretty(relpages*8192) as tamanho FROM pg_class JOIN pg_tables ON relname = tablename ORDER BY relpages DESC limit 10; A partir delas você pode gerar o que precisa. Tome cuidado ao utilizar o relpages pois essa coluna só é atualizada após um VACUUM ou ANALYZE. Então se você executa as rotinas VACUUM e ANALYZE manualmente ou definiu os valores do autovacuum muito altos, você pode ter uma diferença no cálculo do tamanho das tabelas e índices. Por fim, se você utiliza uma versão = 8.1, utilize pg_*relation_size(). -- 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] validação de CNPJ em SQL
Olá pessoal, Após a função que valida CPF, eu produzi uma que valida CNPJ utilizando apenas SQL (é claro :). Divirtam-se! PS para aqueles que copiaram a função CPF, eu fiz algumas correções. [1] http://timbira.com/pg/cpf.sql [2] http://timbira.com/pg/cnpj.sql -- 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] validação de CPF em SQL
Olá pessoal, Fiz uma função [1] que valida um CPF utilizando apenas SQL. Divirtam-se! ;) [1] http://timbira.com/pg/cpf.sql -- 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
Re: [pgbr-geral] validação de CPF em SQL
Osvaldo Kussama escreveu: Para as pessoas que enviaram as outras soluções: o ponto alto da função do Euler é apenas fazer a verificação utilizando declarações SQL e não procedimentos como as funções enviadas. Exatamente Osvaldo. A idéia é utilizar puramente o SQL para fazer uma validação simples. Validações em outras linguagens procedurais eu tenho e são _triviais_ de fazer quando se tem variáveis e estruturas de controle disponíveis. -- 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
Re: [pgbr-geral] validação de CPF em SQL
JUNIN Trabalhando . . . %Segredos - Frejat% escreveu: OK. Apenas quis ajudar A idéia de postar funções de uso geral é válida; tanto é que temos no wiki [1] uma área para isso. [1] http://wiki.postgresql.org/wiki/Snippets -- 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
Re: [pgbr-geral] PostgreSQL integrado ao XAMPP ( WIN XP )
André escreveu: Olá amigos. Gostaria de saber se há possibilidade de integrar o PostgreSQL ao Xampp, utilizo o Windows XP Professional. Procurei no Google, ví que algumas pessoas conseguiram fazê-lo mas não diz como. Seria muito interessante para mim, pois trabalho com banco MySQL e gostaria de migrar aos poucos para PostgreSQL. Existe outro empacotador [1] que fornece o PostgreSQL. Não sei se o XAMPP teria interesse em empacotar o PostgreSQL também. [1] http://bitnami.org/stacks -- 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
Re: [pgbr-geral] libpg funcao PQexecParams
Xharbour suporte escreveu: [Por favor *não* sequestre uma _thread_] Onde posso conseguir um exemplo para a funcao abaixo da lib pq que binde os dados to tipo text,numeric,bool,varchar . char , date, timestamp numa query No manual [1]? Exemplo 3. [1] http://www.postgresql.org/docs/8.3/static/libpq-example.html -- 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
Re: [pgbr-geral] PostgreSQL 8.1 no debian lenny
Fabricio Telles escreveu: Mas... o banco está aparentemente instalado, já configurei o pg_hba e o postgresql.conf, mas não consigo conectar via pgadmin de outra máquina. Você executou um 'pg_ctl reload'? Tem algum firewall entre a máquina que está tentando conectar e o servidor de banco de dados? -- 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
Re: [pgbr-geral] Tipos de busca
Jorge Vilela escreveu: Pessoal, tentei, tentei, tentei e não conseguí chegar em um resultado satisfatório usando tsvector @@ tsquery com trgm. A busca por meias palavras é realmente falha. O suporte a correspondência parcial (aka partial match) na busca textual só foi implementado na 8.4. :( O fato é que, há tempos preciso me livrar desse lLIKE '%%', mas não sei como. Especialmente em casos onde preciso buscar em dois ou mais campos. Com a 8.4 você poderá fazer: euler=# create table foo (a tsvector); CREATE TABLE euler=# insert into foo select 'euler taveira de oliveira'::tsvector from generate_series(1, 1000); INSERT 0 1000 euler=# insert into foo select 'jorge vilela'::tsvector from generate_series(1, 100); INSERT 0 100 euler=# create index fooi on foo using gin (a); CREATE INDEX euler=# select * from foo where a @@ 'vile:*' limit 5; a -- 'jorge' 'vilela' 'jorge' 'vilela' 'jorge' 'vilela' 'jorge' 'vilela' 'jorge' 'vilela' (5 registros) euler=# explain analyze select * from foo where a @@ 'vile:*'; QUERY PLAN --- Bitmap Heap Scan on foo (cost=4.30..13.77 rows=6 width=43) (actual time=0.264..0.470 rows=100 loops=1) Recheck Cond: (a @@ '''vile'':*'::tsquery) - Bitmap Index Scan on fooi (cost=0.00..4.30 rows=6 width=0) (actual time=0.237..0.237 rows=100 loops=1) Index Cond: (a @@ '''vile'':*'::tsquery) Total runtime: 0.739 ms (5 registros) -- 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
Re: [pgbr-geral] RES: RES: RES: Indice parando.
José Augusto de Lima Pereira escreveu: Quanto ao resultado, acabou de ficar pronto o ANALYZE. Bom, o problema é que ele está fazendo uma ordenação no disco que consome 4G e 97% do tempo é gasto nisso. :( Qual o percentual retornado por essa consulta? Você falou em 400k de 4M que seria 10%; neste caso ele usaria o índice. Você executou ANALYZE nessa tabela antes do EXPLAIN ANALYZE? Qual a estrutura da tabela e dos índices bem como a consulta executada? -- 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
Re: [pgbr-geral] Indice parando.
Jose Augusto Pereira escreveu: Criei vários indices diferentes para tentar trabalhar essa tabela, mas em todos os casos acontece a mesma coisa, quando eu passo de 400.000 linhas, o banco para de usar os indices, com isso, se eu processar 400.000 o processamento sai em menos de 1 segundo se eu coloco 400.001 linhas demora 1 hora. Mostre-nos o EXPLAIN ANALYZE da consulta. Tenho um servidor com 4Gb de memoria e processador Xeon Quad X3210. Alguns dos meus principais parâmetros no postgres max_connections = 100 shared_buffers = 2048MB Usar metade da memória para shared_buffers não é uma boa idéia (mesmo tendo poucos usuários). -- 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
Re: [pgbr-geral] Queda de desempenho do SGBD após al teração de tablespace
Leandro Cavalari Soares escreveu: (Ambiente: Suse EL 10, PostgreSQL 8.3, 2 Opteron, 8GB de RAM e 2 discos SCSI 15K de 146GB em RAID 1) Qual a versão do kernel? 2.6.16? É muito antigo; recomendo atualizá-lo. O problema é que ao avançar das horas, ao invés de ganhar desempenho por ter dividido as bases em 2 discos, o fluxo de tratamento dos SQLs caiu drasticamente. Minha aplicação chegou a acumular 500.000 SQLs. Não há erro nos logs. Já reindexei as bases. O SGBD está executando o vacuum normalmente. Não há conexão travada em pg_stat_activity. A máquina está com baixo processamento e baixo uso de disco ... =/ Como você mediu que o desempenho caiu? O que quis dizer com 'acumular 500k sql'? Você disse que está executando o VACUUM normalmente? Mas e o ANALYZE? O autovacuum está ligado? Além disso, você colocou os discos na mesma controladora já existente? Se sim, verificou a taxa de transferência que ela suporta? Se foi em outra controladora, você verificou se não há bugs no driver da controladora? -- 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
Re: [pgbr-geral] RES: Indice parando.
José Augusto de Lima Pereira escreveu: Esse é o resultado do explain verbose. EXPLAIN ANALYZE por favor. As definições de índices e tabelas envolvidas também ajudariam. O PostgreSQL talvez esteja preferindo um _seqscan_ ao invés de um _indexscan_ porque ele está consultando boa parte de sua tabela? O shared_buffers não é o total de memória que meu postgres vai utilizar? Sempre vi falar em usar, 70% da memória total. *Não*. Vide algumas de minhas palestras [1] e artigos de alguns colegas [2] sobre o assunto. [1] http://www.timbira.com/docs.php [2] http://wiki.postgresql.org/wiki/Portugu%C3%AAs -- 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
Re: [pgbr-geral] Arquivos temporários pgsql_tmp
Wagner Bonfiglio escreveu: O problema que eles estão ficando muito grandes e eu não sei exatamente para que servem, por que demoram para ser excluídos (no caso quando não tem mais espaço em disco), por que crescem tanto, etc... Alguém poderia me dar mais informações sobre ele? E principalmente como posso limitar o crescimento deles? Você não disse qual a versão do PostgreSQL está utilizando mas se esta versão for a 8.3, você pode habilitar o parâmetro log_temp_files para coletar o nome e tamanho dos arquivos criados. Como você não sabe quais as consultas estão criando arquivos temporários, eu habilitaria o log de todas as consultas, filtraria somente os comandos SELECT e executaria um EXPLAIN ANALYZE em todos eles. Depois disso, faria uma análise (aka grep 'Disk') nas saídas dos comandos EXPLAIN para verificar quais as consultas que estão gerando todos esses arquivos temporários. Por fim, no mínimo esse comportamento é muito curioso. Os arquivos temporários são transitórios, ou seja, só sobrevivem até o final da transação. Você tem transações abertas a muito tempo ou realiza transações longas no banco? -- 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
Re: [pgbr-geral] Apresentação e primeira pergunta .
Davi Vercillo C. Garcia escreveu: Meu nome é Davi, sou estudante de Ciência da Computação na UFRJ. Tenho interesse em aprender mais sobre administração de banco de dados diversos, incluindo o PostgreSQL. Seja bem vindo! Minha primeira pergunta é: Existem diversos bancos de dados gratuitos e/ou opensource, mas quais são as diferenças (performance, estabilidade, recursos) entre eles ? Especialmente falando de MySQL x PostgreSQL. (Não entender com um flame). Olhe os links no seguinte e-mail [1]. [1] http://archives.postgresql.org/pgsql-advocacy/2009-05/msg5.php -- 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
Re: [pgbr-geral] Enc: Instalação PostgreeSQL - C onexao Bando de Dados
Danilo Mateus Oliveira escreveu: Recebi alguns e-mails para resolver a Conexão do BD, mas não deu certo. Alguns e-mails que recebi para para o PostgreSQL Linux e o que estou usando é Windows. Você olhou este link[1]? Você tem certeza que o serviço está executando? [1] http://agajorte.blogspot.com/2009/03/meu-postgresql-nao-conecta.html -- 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
Re: [pgbr-geral] Problemas com SAVEPOINT
Fabio Galluzzo escreveu: Ae dá erro. Eu até consegui implementar sem o savepoint, mas seria mais interessante usá-lo. Sem saber os passos seguidos e o erro fica difícil supor algo... -- 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
Re: [pgbr-geral] Converter resultados numéricos de e n_US.utf-8 para pt_BR.utf-8 na consulta.
Bruno Simioni escreveu: Apesar do PostgreSQL ajustar as variáveis de dezenas e centesimos a partir de postgresql.conf, deveria haver uma outra forma de utilizar essas variáveis em pg/plsql, por exemplo, para resolver o problema, ao invés de modificar o ambiente, como por exemplo set lc_numeric . Há. euler=# \! cat /tmp/teste CREATE OR REPLACE FUNCTION public.teste() RETURNS void LANGUAGE plpgsql AS $function$ declare i text; begin select to_char(123456.789, '999G999G999D99') into i; raise notice 'i: %', i; set local lc_numeric to 'en_US'; select to_char(123456.789, '999G999G999D99') into i; raise notice 'i: %', i; end; $function$ uler=# show lc_numeric; lc_numeric - pt_BR.UTF-8 (1 registro) euler=# select teste(); NOTA: i: 123.456,79 NOTA: i: 123,456.79 teste --- (1 registro) euler=# show lc_numeric; lc_numeric - pt_BR.UTF-8 (1 registro) -- 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
Re: [pgbr-geral] Converter resultados numéricos de e n_US.utf-8 para pt_BR.utf-8 na consulta.
Bruno Simioni escreveu: Não gostaria de utilizar as funções que determinam variáveis de ambiente para isso, e gostaria da conversão via funções ou to_char, ou expressões regulares, ou outras. Por que fazer da maneira difícil? Qual o problema em ajustar o lc_numeric no postgresql.conf? Se ele não pode ser ajustado, por que não fazer isso na própria sessão (set lc_numeric to 'pt_BR')? Acho que está indo pela maneira mais difícil para uma coisa tão simples. -- 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
Re: [pgbr-geral] Restaurar Banco de Dados
Rafael Domiciano escreveu: Segundo, você salvou quais pastas do sistema? Espero que tenha sido as data, xlog e clog. Eu tinha feito isso uma vez, quando estava com problema num hd e o banco não subia, e essas pastas foram suficientes para mim. Acho que você andou trocando os nomes ali. O postgres não possui um diretório data no agrupamento de banco de dados. Para recuperar ser feita com sucesso você deve: (i) parar o serviço e (ii) copiar o diretório do agrupamento de banco de dados (Onde encontrar? Variável PGDATA, C:\Program Files\PostgreSQL\8.3\data, /var/lib/postgresql/8.3/main ou /meu/caminho/aqui são alguns exemplos). Agora, se você apenas tem a pasta data, você pode tentar usar o comando: pg_resetxlog. Não entendi... Novamente acho que você trocou os nomes. -- 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
Re: [pgbr-geral] pg_dump zoado
armando oliveira escreveu: Como faço pra vir certinho sem aqueles codigos loucos no meio e invez de copy/. que quando roda denovo da pau vir com inserts dos dados?? Sugiro ler a mensagem do Sr. Telles [1] *urgentemente* (principalmente os itens 2, 3 e 5). Sem saber qual comando você está utilizando fica difícil supor algo. Além disso, não consegui decifrar o que seria codigos loucos e roda denovo da pau. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-May/015419.html -- 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
Re: [pgbr-geral] Campanha dos 5 pontos para melhorar o nível da lista
Fernando Ike escreveu: [corte] Quando os novos tentam ajudar ou perguntar acontece uma grande frustração pois as respostas são mais lentas, existe discussão sobre o que fazer e como fazer. Não conhecem porque *não* querem. As regras são *claramente* apresentadas ao se inscrever na lista de usuários (aka esta lista). Se tem gente cobrando uma conduta é porque a mesma está descrita em algum lugar. Esta frustração é maior em grupo de usuários pois há uma falta de objetivo claro do grupo de usuário, pois qual o objetivo principal? É ter novos usuários ou ter novos voluntários contribuindo com o PostgreSQL? Ambos. Isso não quer dizer que novos usuários devam ter uma conduta desleixada. Pelo contrário, se é novato, deveria observar para aprender com aqueles que estão ali a mais tempo. Um pergunta mal formulada, mal escrita eu costumo não ler, uma pergunta clara e se já não estiver respondida por alguém da lista eu respondo. Concordo contigo. Mas, às vezes, temos que dar uns puxões de orelha como já fizeram vários gurus da lista como Mello, Dutra e por último o Telles. O seu email sempre me traz uma pergunta recorrente: Qual o objetivo do grupo de usuários PostgreSQL Brasil Eu respondi esta pergunta a exatamente duas semanas durante a palestra Universo PostgreSQL [1] no PGDay-RO. Eis a resposta: (i) divulgar o PostgreSQL (ii) incentivar o uso (iii) apoiar eventos relacionados [1] http://timbira.com/presentations/pgday_ro_2009/universo_pg.pdf -- 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
Re: [pgbr-geral] Salvar a definição de funç ões via psql
Newton Teixeira do Nascimento Júnior escreveu: ERRO: função pg_catalog.pg_get_functiondef(integer) não existe Ops... Esta função é nova e só está disponível no 8.4. :( Para fazer funcionar no 8.2 você teria que extrair a função pg_get_functiondef (backend/utils/adt/ruleutils.c), compilá-la e carregá-la no PostgreSQL. Como faço pra obter também as definições de visões, tabelas e triggers que tenham apresentam um certo padrão nos desses objetos ? Você consegue as definições das tabelas e visões utilizando o pg_dump com opção -t. Gatilhos somente com a função pg_get_triggerdef. Outra Euler, como salvar o resultado dos select’s (dentro do for) em um arquivo texto? Redirecione a saída para um arquivo texto. -- 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
Re: [pgbr-geral] Salvar a definição de funções via psql
Roberto Mello escreveu: 2009/5/8 Newton Teixeira do Nascimento Júnior newton.jun...@eletronorte.gov.br: Existe algum comando pra salvar a definição de todas as funções (functions) de um banco para um arquivo via psql ? O pg_dump faz. Sim, mas ele *não* salva _somente_ as definições das funções. Eu tenho um script [1] que faz isso exatamente isso. [1] http://www.timbira.com/pg/dumpfuncs.sh -- 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
Re: [pgbr-geral] vacuum em 2 ou mais tabelas ao mesmo tempo
jorge sanfelice escreveu: Pergunto isso, porque em alguns momentos tenho que executar vaccum analyze ou vacuum full em 5,10, 20 etc... tabelas em um banco que tem mais de 2 mil tabelas e executar um vaccum de cada vez se torna algo trabalhoso. Sei que poderia fazer um processo onde eu passaria as tabelas como entrada e ele executaria isso pra mim em um laço, Mas a idéia é, se isso nao existe, sera que nao seria algo legal de ser acrescentado a outras versoes do postgresql. Por que não utilizar o autovacuum? Com isso, você não precisa se preocupar com VACUUM e ANALYZE nas tabelas. -- 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
Re: [pgbr-geral] Função em C no PostgreSQL
Anderson escreveu:
Alguém sabe me dizer o porque deste erro na hora de criar uma função no
banco de dados usando uma função feita em C.
Porque *não* é assim que cria funções em C no PostgreSQL. Vide exemplos em [1].
Erro:
ERROR: could not load library /usr/local/pgsql/lib/teste.so:
/usr/local/pgsql/lib/teste.so: undefined symbol: ECPGdo
SQL state: 58P01
Estou utilizando o PostgreSQL 8.2.6 com o Ubuntu 9.04. Já tentei também
no PostgreSQL 8.3.6, o erro é o mesmo.
O ECPG [2] é uma linguagem para utilização de SQL embutido em um programa C.
Abaixo eu ilustro um exemplo bem simples:
eu...@harman ~ $ cat /tmp/t1.pgc
#include stdio.h
int main(void)
{
ECPGdebug(1, stderr);
exec sql connect to eu...@localhost:5433;
exec sql create table foo (a int, b int);
exec sql select * from foo;
exec sql drop table foo;
exec sql disconnect;
return 0;
}
eu...@harman ~ $ ./install/bin/ecpg /tmp/t1.pgc
eu...@harman ~ $ gcc -o /tmp/t1 -I./install/include /tmp/t1.c -lecpg
eu...@harman ~ $ /tmp/t1
[8263]: ECPGdebug: set to 1
[8263]: ECPGconnect: opening database euler on localhost port 5433
[8263]: ecpg_execute line 8: QUERY: create table foo ( a int , b int ) with 0
parameter on connection euler
[8263]: ecpg_execute line 8: using PQexec
[8263]: ecpg_execute line 8 Ok: CREATE TABLE
[8263]: ecpg_execute line 9: QUERY: select * from foo with 0 parameter on
connection euler
[8263]: ecpg_execute line 9: using PQexec
[8263]: ecpg_execute line 9: Correctly got 0 tuples with 2 fields
[8263]: raising sqlcode 100 in line 9, 'No data found in line 9.'.
[8263]: ecpg_execute line 10: QUERY: drop table foo with 0 parameter on
connection euler
[8263]: ecpg_execute line 10: using PQexec
[8263]: ecpg_execute line 10 Ok: DROP TABLE
[8263]: ecpg_finish: Connection euler closed.
[1] http://www.postgresql.org/docs/8.3/static/xfunc-c.html
[2] http://www.postgresql.org/docs/8.3/static/ecpg.html
--
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
Re: [pgbr-geral] Problemas de conexão entre o Hibern ate/c3p0 e o Postgres 8.3 quando aumenta o número de c onexões ESTABELECIDAS e em TIME_WAIT
Leandro de Almeida Rodrigues escreveu: Após um certo tempo, não definido, o hibernate gera inúmeras conexões com a porta 5432 do postgres e este, passa a negar as demais conexões ao hibernate causando uma excessão: Acho que você está perguntando na lista errada. Que tal usar o oráculo (aka google) ou uma lista especializada em hibernate/java? chute provavelmente você esqueceu de utilizar o método close() em algum ponto /chute Estamos utilizando o *Postgres na versão 8.3.7-0lenny1* , *Tomcat 5.5.26-5*, *Sun-Java 1.5.0-17-0.1*, conectores: *hibernate3.jar*, *c3p0-0.8.5.2.jar* e *postgresql-8.0.309.jdbc3.ja*r. Por que estás utilizando o driver 8.0? A série 8.0 já está no 323 mas eu aconselharia utilizar o 8.3 build 604 [1]. Peço a ajuda encarecida dos caros colegas, pois este problema já persiste a algum tempo e não estamos conseguindo suporte especializado para resolvê-lo. Você já tentou uma lista especializada em hibernate ou java [2]? [1] http://jdbc.postgresql.org/download.html [2] http://www.soujava.org.br/pages/viewpage.action?pageId=1376261 -- 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
