Re: [pgbr-geral] BUG - PGBadger -Temporary files
Flávio, Você acha que a consulta que gerou o temp foi um select de uma única tabela, indo pela PK, sem order by, sem nada, resultando uma única linha? Um temp de mais de 70MB? Pois esse select é o que está abaixo da criação do temp, e a que está acima é um select distinct processotr1_.id_processo_trf as id1_6_, Esse select cima é que gerou o temp e não o de baixo. ___ 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 e NFS
2015-03-05 12:25 GMT-04:00 Émerson Eng. emersonnar...@gmail.com: Estou analisando uma demanda onde Postgres faria parte de uma VM que contém diversas aplicações. Basicamente uma mesma VM é executada em nuvens diferentes, conforme regras definidas, localização e característicias dessa nuvem. Fiz isso utilizando o recurso de snapshot do LVM e funcionava muito bem, e não precisava mexer com NFS e sua latência e outros problemas. 1) Diretório do PG (e da VM com tudo na verdade) ficava num volume LVM 2) Criava um snapshot do volume, ou seja, um volume temporário onde apenas as modificações ocupariam espaço em disco. 3) Levantava a VM utilizando este novo volume em snapshot do LVM 4) Quando a VM acabava seu serviço e era derubada, desmonstava e destruia o volume en snapshot, e pronto. Liberava o espaço com as modificações, e o volume original não havia sofrido nenhuma alteração. Nunca haverá mais que uma VM executando ao mesmo tempo. Esses nunca geralmente nunca persistem. Com essa alternativa do LVM você pode levantar quantas VMs você tiver recursos (CPU, buffers, e espaço para os snapshot) para aguentar. À época eu também utilizei isso com o OpenVZ, que cria containers no Linux. Se não me engano o OpenVZ foi renomeado e melhorado recentemente, a há vários tipos de containers similares disponíveis por aí. Eu gosto muito de containers por que são rápidos, práticos, e leves. Há desvantagens também, claro. Analise o que fica melhor para você. []s, Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BUG - PGBadger -Temporary files
A query que gerou o temp foi o select distinct (Acima) e não a que apareceu no pgbadger (abaixo da criação do temp) Caro Luiz Carlos, o PostgreSQL escreve no log a consulta que gerou o temporário *sempre* abaixo da linha que informa o tamanho do arquivo gerado. Não vejo bug algum aí e o PgBadger está corretíssimo, informou a consulta e o tamanho exato do temporário gerado por ela. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
2015-03-05 13:10 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: No mínimo, declare CPF e CNPJ como chaves também. Temos apenas um campo para estes dois, chamado nr_cpf_cgc( varchar(14) ), sendo que é um índice único com validação para CPF e CNPJ na inclusão. Exatamente o que sugeri, parabéns. Assim dá para respirar e esperar o momento de normalizar. Você poderia até usar isso como chave primária (e estrangeira nas ‘filhas’), o que tornaria essa tabela menor, economizaria um índice e suas atualizações, e talvez evitasse algumas junções. Mas o mais urgente já fizeste. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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 e NFS
2015-03-05 12:44 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Utilize NFSv4, um kernel recente, numa distribuição com suporte correto e atualizada. Monte o sistema de arquivos em modo síncrono. O desempenho pode ficar abaixo do esperado mas isso depende de sua aplicação, rede, discos e resto do hardware em geral. Teste tudo. Dividir o diretório do cluster pela rede não faz sentido na maioria dos casos, talvez para algum tipo de failover, explique melhor sua necessidade. Recentemente tem-se usado NFS em alguns storages modernos que oferecem a montagem dessa forma, mas um bom iSCSI ainda é a melhor pedida Obrigado pelas dicas Flavio. De fato, iSCSI seria ótimo ou mesmo os mecanismos nativos de replicação do Postgres. Apenas queria a opinião de alguém que já havia usado. Estou analisando uma demanda onde Postgres faria parte de uma VM que contém diversas aplicações. Basicamente uma mesma VM é executada em nuvens diferentes, conforme regras definidas, localização e característicias dessa nuvem. Nunca haverá mais que uma VM executando ao mesmo tempo. O *storage* de persistência fica sempre no mesmo lugar. Logo, nenhum dado que deva ser persistido fica na VM. A VM é descartável e deve fazer todo o processamento. Quando necessário a VM de um ponto é desligada e é ativada uma VM de outro ponto. ___ 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 e NFS
2015-03-05 13:29 GMT-03:00 Émerson Eng. emersonnar...@gmail.com: Infelizmente não posso instalar aplicações no servidor de storage. Tenho apenas uma pasta acessível via NFS e, um usuário via SSH sem permissão root ou de instalar qualquer coisa, ou mesmo abrir qualquer portas. Não espere desempenho ou confiabilidade extremas. É administrável, mas implica latência e acrescenta ponto de falha. Mesmo virtualização costuma acrescentar latência e pontos de falha. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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 e NFS
Infelizmente não posso instalar aplicações no servidor de storage. Tenho apenas uma pasta acessível via NFS e, um usuário via SSH sem permissão root ou de instalar qualquer coisa, ou mesmo abrir qualquer portas. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] pg_basebackup lento
Boa tarde a todos, estou implementando o backup com o pg_basebackup, mas esta muito lento. utlizei os comandos a seguir: 1 - pg_basebackup -h 127.0.0.1 -U bkp_user -D /home/bkp -Ft -z 2 - pg_basebackup -h 127.0.0.1 -U bkp_user -D /home/bkp O database ocupa em média 377GB, executando o backup compactado através do comando (1) leva em média 12 horas para finalizar o mesmo, e o comando(2) leva quase o mesmo tempo. Utilizo um servidor com dois processadores Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz que emulam 24 processadores e 64 GB de memória RAM. O Load da máquina esta baixo em média fica com 0.43 0.54 0.60. O arquivo de backup esta sendo armazenado um array de discos diferente de onde esta alocado o cluster do Postgresql, onde não a escrita de disco não esta sendo o gargalo. Não há um modo de adicionar mais jobs no comando pg_basebackup? Atenciosamente Eduardo Rodrigues ___ 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 e NFS
Infelizmente não posso instalar aplicações no servidor de storage. Tenho apenas uma pasta acessível via NFS e, um usuário via SSH sem permissão root ou de instalar qualquer coisa, ou mesmo abrir qualquer portas. Nesse caso é fria instalar o diretório do cluster nesse servidor NFS, desculpe a franqueza. O DBA deve ter o poder sobre seus recursos para administrá-los corretamente, pelo menos ele deve ter acesso a quem o tenha para poder orientar e discutir. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_basebackup lento
Realmente o problema é IO, vou analisar o que esta ocorrendo para poder identificar o que esta causando esse gargalo de disco. Obrigado pela ajuda Em Qui, 2015-03-05 às 14:17 -0300, Euler Taveira escreveu: On 04-03-2015 15:26, Eduardo Rodrigues wrote: estou implementando o backup com o pg_basebackup, mas esta muito lento. utlizei os comandos a seguir: Você falou em 'load' mas o que interessa é IO. Qual é a saída do vmstat ou iostat ao executar o pg_basebackup? Não há um modo de adicionar mais jobs no comando pg_basebackup? Não. E também não adiantaria pois o gargalo durante a operação não é CPU e sim IO. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Stream Replication x Slony
On 05-03-2015 12:56, Francisco Porfirio wrote: Não replicar DDL's seria um gargalo para mim, tendo em vista que tenho atualizações com uma boa frequencia das apps. Como eu disse ele não replica *automaticamente*. Você pode fazer isso manualmente usando o slonik (vide EXECUTE SCRIPT [1]). Sobre o large objects, no modelo Stream Replication existe alguma restrição, ou funciona bem? No SR não há restrições. [1] http://www.slony.info/documentation/2.2/stmtddlscript.html -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo de backup
On 04-03-2015 14:29, Eduardo Rodrigues wrote: aproveitando o tópico desse e-mail Não sequestre um assunto mesmo se ele for similar a sua dúvida. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
2015-03-05 12:55 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? Sim, cd_cliente é a chave primária. Essa é uma tabela que foi criada em nosso sistema em 1998 e não está normalizada como deveria, mas acho que nem vem ao caso. Essa tabela armazena clientes PF e PJ, por isso a PK não é o CPF do cliente. Possivelmente não é viável ou interessante mudar tudo, mas a chave primária poderia, em tese, ser definida sobre um atributo ‘CPF/CNPJ’, com restrições de integridade tanto para validar CPF ou CNPJ quanto para, na dificuldade de normalizar, garantir que outros atributos estão consistentes com o CPF/CNPJ. No mínimo, declare CPF e CNPJ como chaves também. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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_basebackup lento
On 04-03-2015 15:26, Eduardo Rodrigues wrote: estou implementando o backup com o pg_basebackup, mas esta muito lento. utlizei os comandos a seguir: Você falou em 'load' mas o que interessa é IO. Qual é a saída do vmstat ou iostat ao executar o pg_basebackup? Não há um modo de adicionar mais jobs no comando pg_basebackup? Não. E também não adiantaria pois o gargalo durante a operação não é CPU e sim IO. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo de backup
Boa tarde a todos, aproveitando o tópico desse e-mail: estou implementando o backup com o pg_basebackup, mas esta muito lento. utlizei os comandos a seguir: 1 - pg_basebackup -h 127.0.0.1 -U bkp_user -D /home/bkp -Ft -z 2 - pg_basebackup -h 127.0.0.1 -U bkp_user -D /home/bkp O database ocupa em média 377GB, executando o backup compactado através do comando (1) leva em média 12 horas para finalizar o mesmo, e o comando(2) leva quase o mesmo tempo. Utilizo um servidor com dois processadores Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz que emulam 24 processadores e 64 GB de memória RAM. Não já um modo de adicionar mais jobs no comando pg_basebackup? Atenciosamente Eduardo Rodrigues Em Ter, 2015-03-03 às 12:07 -0300, Euler Taveira escreveu: On 03-03-2015 11:47, Danilo Silva wrote: Em 3 de março de 2015 11:00, Euler Taveira eu...@timbira.com.br escreveu: Existem métodos onde podemos acelerar o tempo para execução? No pg_basebackup somente a opção --checkpoint=fast. Se você optar por não compactar (opção --gzip) também vai levar menos tempo, porém, vai ocupar mais espaço. Certo, fiz um teste em uma base com 16GB (base + tablespaces): com a opção -Z 9 levou 38 minutos e no final o diretorio ficou com 1,8GB sem a opção -Z9 levou 8 minutos e no final o diretorio ficou com 13GB. Neste caso, onde está os outros 3GB? Pergunto isso para tentar saber se irá reduzir os 300GB que estão em produção. Como você não mostrou o comando utilizado fica difícil saber porque a diferença foi tão grande. Baseado no que você descreveu, com mais compressão (9) leva mais tempo para produzir um arquivo menor. Vale ressaltar que o percentual de compressão tem relação direta com os tipos de dados utilizados (por exemplo, se você armazena imagens ou arquivos a compactação vai ser menor do que se você usar tipos textuais) e a manutenção (tabelas inchadas irão consumir mais tempo e espaço do backup físico). ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PostgreSQL e NFS
Gostaria da opinião especialmente de quem já utilizou NFS(Network File System) junto ao PostgreSQL para dividir a pasta *data* pela rede. ___ 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 e NFS
2015-03-04 17:34 GMT-03:00 Émerson Eng. emersonnar...@gmail.com: Gostaria da opinião especialmente de quem já utilizou NFS(Network File System) junto ao PostgreSQL para dividir a pasta data pela rede. Nunca usei, mas não é necessário provar um ovo para saber que está podre. Eu, particularmente, gosto muito do NFS. Mas não é o caso de introduzir um ponto de falha desnecessariamente. Não só ponto de falha como latência também. Se você tem discos numa máquina e o PostgreSQL na outra, considere mover ou os discos ou o PostgreSQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
Para sua consulta, o índice ideal seria: CREATE INDEX ON cliente (cd_filial_inclusao, cd_cliente); Assim é possível buscar rapidamente o cd_filial_inclusao pelo número exato e então só pegar o último elemento, com maior cd_cliente. Interessante. Vou fazer uns testes aqui, apenas para laboratório, pois como é uma consulta executada eventualmente, talvez mais um índice só para isso não seja interessante. O índice cd_filial_inclusao, dh_inclusao sim é necessário, pois é utilizado em muitas pesquisas que estão dentro dos nosso sistemas. Agradeço a ajuda. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] WEBINAR DEXTRA: PostgreSQL 9.4: O que há de novo?
Pessoal, Amanhã teremos um webinar sobre PostgreSQL 9.4: *Data: *05/ MARÇO *Horário:* 11:30hr *ASSISTA 'AO VIVO' VIA HANGOUT https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119-* Os webinares da Dextra utilizam a ferramenta Hangout On Air do Google, para saber mais, clique aqui http://www.google.com/+/learnmore/hangouts/?utm_source=Webinars+Dextrautm_campaign=982ae60119-Dextra+%7C+Webinars+2015+-+%C3%89+amanh%C3%A3+-+05marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- . Contamos com a participação de vocês! -- Matheus Ricardo Espanhol --- Dextra Sistemas http://www.dextra.com.br/postgres www.pganalytics.io ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
2015-03-05 10:28 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: Ao executar a seguinte consulta : SELECT max( cd_cliente ) FROM cliente WHERE cd_filial_inclusao = 563 O resultado do plano de acesso é o seguinte: Result (cost=29.31..29.32 rows=1 width=0) (actual time=291588.847..291588.847 rows=1 loops=1) Output: $0 Buffers: shared hit=323106 read=1181788 InitPlan 1 (returns $0) - Limit (cost=0.43..29.31 rows=1 width=12) (actual time=291588.840..291588.840 rows=1 loops=1) ... - Index Scan Backward using pk_cliente on cliente (cost=0.43..377539.21 rows=13071 width=12) (actual time=291588.837..291588.837 rows=1 loops=1) ... Execution time: 291588.916 ms 1 rows returned (execution time: 11,466 sec; total time: 11,498 sec) A tabela em questão ( cliente ), tem 2.435.230 linhas com 341 ( cd_filial_inclusao ) diferentes. Um dos índices da tabela é composto por cd_filial_inclusao, dh_inclusao. CREATE INDEX idx_cliente_inclusao ON cliente USING btree (cd_filial_inclusao, dh_inclusao); Neste caso a consulta não deveria utilizar o índice acima para realizar a busca? Pois até onde tenho conhecimento, ainda que um índice seja composto, se eu utilizar as colunas na ordem do índice na cláusula where, ainda que não utilize todas as colunas que compõe o índice, a busca deveria utilizar ele. Esse índice poderia sim ser usado, mas aí o PostgreSQL deveria fazer uma operação de ordenação (Sort) após a filtragem dos registros. No caso foi escolhido o índice (PK) em cd_cliente exatamente para evitar a ordenação, assim usa o índice para trazer os maiores valores (para aplicar no max) e filtra cd_filial_inclusao pela tabela. Para sua consulta, o índice ideal seria: CREATE INDEX ON cliente (cd_filial_inclusao, cd_cliente); Assim é possível buscar rapidamente o cd_filial_inclusao pelo número exato e então só pegar o último elemento, com maior cd_cliente. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
Como é que se chamava isso, ‘problema A-B’? Onde a pessoa pergunta o que quer fazer, mas não explica sua real necessidade? Problema XY - Você quer fazer X, acha que Y é uma boa solução e pergunta como fazer Y. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? Sim, cd_cliente é a chave primária. Essa é uma tabela que foi criada em nosso sistema em 1998 e não está normalizada como deveria, mas acho que nem vem ao caso. Essa tabela armazena clientes PF e PJ, por isso a PK não é o CPF do cliente. O cd_cliente é um char(11), composto pelo cd_filial_inclusao ( este é um numérico com 4 dígitos ) e mais o sequencial do cadastro por cd_filial_inclusao, com isso temos o cliente 0013001, o 0013002, o 0634001, 0634002, ... Quando o campo cd_filial_inclusao foi criado, muito antigamente, foi para remover as pesquisas que utilizavam where substring( cd_cliente, 0, 4 ) para ganhar performance. Temos em nossa rede um Servidor Sybase Entrerprise, que tem a mesma tabela, com os mesmos registros, e o plano de acesso utiliza o índice. Você tentou fazer um ANALYZE na tabela cliente antes da consulta. Teve outro resultado? Sim, fiz um ANALIZE antes e o resultado foi o mesmo. Já executei o REINDEX, mas nada mudou. Euler, você explicou muito bem o porque o banco pode optar em não utilizar o índice, e tirou a minha dúvida. Essa consulta não está em nenhum sistema, mas eventualmente eu executo, então eu só queria mesmo entender o que estava ocorrendo. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-05 12:49 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Como é que se chamava isso, ‘problema A-B’? Onde a pessoa pergunta o que quer fazer, mas não explica sua real necessidade? Problema XY - Você quer fazer X, acha que Y é uma boa solução e pergunta como fazer Y. Merci ! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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 e NFS
Gostaria da opinião especialmente de quem já utilizou NFS(Network File System) junto ao PostgreSQL para dividir a pasta /data/ pela rede. Utilize NFSv4, um kernel recente, numa distribuição com suporte correto e atualizada. Monte o sistema de arquivos em modo síncrono. O desempenho pode ficar abaixo do esperado mas isso depende de sua aplicação, rede, discos e resto do hardware em geral. Teste tudo. Dividir o diretório do cluster pela rede não faz sentido na maioria dos casos, talvez para algum tipo de failover, explique melhor sua necessidade. Recentemente tem-se usado NFS em alguns storages modernos que oferecem a montagem dessa forma, mas um bom iSCSI ainda é a melhor pedida. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-05 12:44 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Dividir o diretório do cluster pela rede não faz sentido na maioria dos casos, talvez para algum tipo de failover, explique melhor sua necessidade. Como é que se chamava isso, ‘problema A-B’? Onde a pessoa pergunta o que quer fazer, mas não explica sua real necessidade? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Stream Replication x Slony
Obrigado pela Resposta Euler, Não replicar DDL's seria um gargalo para mim, tendo em vista que tenho atualizações com uma boa frequencia das apps. Sobre o large objects, no modelo Stream Replication existe alguma restrição, ou funciona bem? Em 5 de março de 2015 11:51, Euler Taveira eu...@timbira.com.br escreveu: On 04-03-2015 16:08, Francisco Porfirio wrote: Atualmente estou usando o postgres 9.3.5, e estudando uma solução que sejá mais adequada para a minha realidade. Tenho um Server com vários databases, e gostaria de criar um slave para ter a replicação de alguns destes, não todos. Pelo que já li, através do Streaming replication, só consigo fazer a replicação de todos os databases, isso procede? Sim. Este seria um fator decisivo para que eu venha a fazer a minha replicação com Slony? Sobre a experiência de vocês com Slony, algo de negativo que vocês possam repassar? É um software maduro. Vale ressaltar que: * não replica DDLs automaticamente; * não replica large objects automaticamente; * não replica alteração em roles; * replicação com gatilhos pode ser tornar um gargalo se houver uma quantidade muito grande de servidores/bancos de dados/tabelas. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente Francisco Porfirio Ribeiro Neto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
Para sua consulta, o índice ideal seria: CREATE INDEX ON cliente (cd_filial_inclusao, cd_cliente); Assim é possível buscar rapidamente o cd_filial_inclusao pelo número exato e então só pegar o último elemento, com maior cd_cliente. Matheus, apresento o retorno da sua dica: __ Result (cost=3.64..3.65 rows=1 width=0) (actual time=0.647..0.647 rows=1 loops=1) Output: $0 Buffers: shared hit=4 InitPlan 1 (returns $0) - Limit (cost=0.43..3.64 rows=1 width=12) (actual time=0.643..0.643 rows=1 loops=1) Output: ((cliente.cd_cliente)::text) Buffers: shared hit=4 - Index Only Scan Backward using cliente_cd_filial_inclusao_cd_cliente_idx on cliente (cost=0.43..48144.34 rows=14976 width=12) (actual time=0.640..0.640 rows=1 loops=1) Output: cliente.cd_cliente Index Cond: ((cliente.cd_filial_inclusao = 563) AND (cliente.cd_cliente IS NOT NULL)) Heap Fetches: 1 Buffers: shared hit=4 Planning time: 6.279 ms Execution time: 0.721 ms 1 rows returned (execution time: 0 ms; total time: 47 ms) __ Perfeito. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
Possivelmente não é viável ou interessante mudar tudo, mas a chave primária poderia, em tese, ser definida sobre um atributo ‘CPF/CNPJ’, com restrições de integridade tanto para validar CPF ou CNPJ quanto para, na dificuldade de normalizar, garantir que outros atributos estão consistentes com o CPF/CNPJ. No mínimo, declare CPF e CNPJ como chaves também. Temos apenas um campo para estes dois, chamado nr_cpf_cgc( varchar(14) ), sendo que é um índice único com validação para CPF e CNPJ na inclusão. Obrigado pela ideia, e a normalização está na lista de pendências, mas o medo de começar é grande. Para ter uma ideia, temos todos os campos de endereço nessa tabela, gerando uma redundância enorme, e esse é só um exemplo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] pg_basebackup lento
Evite o top-post Realmente o problema é IO, vou analisar o que esta ocorrendo para poder identificar o que esta causando esse gargalo de disco. Ou rede. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BUG - PGBadger -Temporary files
Segue resultado do pgbadger RankSizeQuery176.05 MiB SELECT processo0_.id_processo AS id1_189_0_, processo0_.nm_actor_id AS nm2_189_0_, processo0_.id_caixa ASid12_189_0_, processo0_.ds_complemento AS ds3_189_0_, processo0_.dt_fim AS dt4_189_0_, processo0_.dt_inicio AS dt5_189_0_, processo0_.nr_duracao AS nr6_189_0_, processo0_.id_fluxo AS id13_189_0_, processo0_.id_jbpm ASid7_189_0_, processo0_. ds_nm_usu_cadastro_processo AS ds8_189_0_, processo0_.nr_processo AS nr9_189_0_,processo0_.nr_processo_origem AS nr10_189_0_, processo0_. nr_processo_temp AS nr11_189_0_, processo0_.id_status ASid14_189_0_, processo0_.id_usuario_cadastro_processo AS id15_189_0_ FROM tb_processo processo0_ WHEREprocesso0_.id_processo = $1; -- Aqui é uma PK [ *Date:* 2015-02-18 21:09:24 - *Database:* xxx - *User:* xxx (49926) 0:60/522437 ] Segue Log 2015-02-18 21:09:16 BRT [13660]: [5-1] db=pxxx...xxx (49926) 0:60/522437 LOG: duration: 5306.735 ms execute unnamed: select count(distinct processopa0_.id_processo_trf) as col_0_0_ from tb_proc_parte_expediente processopa0_ left outer join tb_processo_trf processotr1_ on processopa0_.id_processo_trf=processotr1_.id_processo_trf left outer join tb_processo_caixa_adv_proc caixasrepr2_ on processotr1_.id_processo_trf=caixasrepr2_.id_processo_trf inner join tb_processo_parte processopa4_ on processotr1_.id_processo_trf=processopa4_.id_processo_trf left outer join tb_proc_parte_represntante processopa5_ on processopa4_.id_processo_parte=processopa5_.id_processo_parte, tb_pessoa pessoa8_ inner join tb_usuario pessoa8_1_ on pessoa8_.id_pessoa=pessoa8_1_.id_usuario inner join tb_usuario_login pessoa8_2_ on pessoa8_.id_pessoa=pessoa8_2_.id_usuario, tb_orgao_julgador orgaojulga10_ where processopa4_.id_pessoa=pessoa8_.id_pessoa and processotr1_.id_orgao_julgador=orgaojulga10_.id_orgao_julgador and (processopa5_.id_representante=$1 and processopa4_.id_pessoa=processopa0_.id_pessoa_parte or processopa0_.id_pessoa_parte in ($2)) and (processopa0_.id_resposta is null) and ( not (exists (select processopa7_.id_proc_parte_representante from tb_proc_parte_represntante processopa7_ where processopa4_.id_processo_parte=processopa7_.id_processo_parte)) or processopa5_.in_situacao=$3 or pessoa8_.id_pessoa=$4) and orgaojulga10_.id_jurisdicao=$5 and (caixasrepr2_.id_caixa_adv_proc is null) and processopa0_.in_fechado=$6 and processotr1_.cd_processo_status=$7 and processopa4_.in_situacao=$8 and (processopa0_.dt_ciencia_parte is not null) limit $9 2015-02-18 21:09:16 BRT [13660]: [6-1] db=pxxx...xxx (49926) 0:60/522437 DETAIL: parameters: $1 = '144859', $2 = '144859', $3 = 'A', $4 = '144859', $5 = '2', $6 = 'f', $7 = 'D', $8 = 'A', $9 = '1' 2015-02-18 21:09:24 BRT [13660]: [7-1] db=pxxx...xxx (49926) 0:60/522437 LOG: duration: 7384.559 ms execute unnamed: select distinct processotr1_.id_processo_trf as id1_6_, processotr1_.nr_ano as nr2_6_, processotr1_.in_apreciado_justica_gratuita as in3_6_, processotr1_.in_apreciado_segredo as in4_6_, processotr1_.in_apreciado_sigilo as in5_6_, processotr1_.in_apreciado_tutela_liminar as in6_6_, processotr1_.id_cargo as id36_6_, processotr1_.id_classe_judicial as id37_6_, processotr1_.id_cl_judicial_outra_instancia as id38_6_, processotr1_.id_competencia as id39_6_, processotr1_.dt_autuacao as dt7_6_, processotr1_.dt_distribuicao as dt8_6_, processotr1_.dt_sugestao_sessao as dt9_6_, processotr1_.ds_proc_referencia as ds10_6_, processotr1_.in_deve_marcar_audiencia as in11_6_, processotr1_.dt_transitado_julgado as dt12_6_, processotr1_.id_endereco_wsdl as id40_6_, processotr1_.id_estrutura_inicial as id41_6_, processotr1_.in_outra_instancia as in13_6_, processotr1_.in_inicial as in14_6_, processotr1_.nr_instancia as nr15_6_, processotr1_.in_incidente as in16_6_, processotr1_.id_jurisdicao as id42_6_, processotr1_.in_justica_gratuita as in17_6_, processotr1_.id_localizacao_inicial as id43_6_, processotr1_.in_mandado_devolvido as in18_6_, processotr1_.id_municipio_fato_principal as id44_6_, processotr1_.nr_digito_verificador as nr19_6_, processotr1_.nr_identificacao_orgao_justica as nr20_6_, processotr1_.nr_origem_processo as nr21_6_, processotr1_.nr_sequencia as nr22_6_, processotr1_.ds_observacao_segredo as ds24_6_, processotr1_.id_orgao_julgador as id45_6_, processotr1_.id_orgao_julgador_cargo as id46_6_, processotr1_.id_orgao_julgador_colegiado as id47_6_, processotr1_.id_orgao_julgador_revisor as id48_6_, processotr1_.id_pes_apreciou_jus_gratuita as id49_6_, processotr1_.id_pessoa_marcou_julgamento as id50_6_, processotr1_.id_pessoa_marcou_pauta as id51_6_, processotr1_.id_pessoa_marcou_revisado as id52_6_, processotr1_.id_pessoa_relator_processo as id53_6_, processotr1_.id_proc_referencia as id54_6_, processotr1_.cd_processo_status as cd25_6_, processotr1_.in_pronto_revisao as in26_6_, processotr1_.in_revisado as in27_6_, processotr1_.in_segredo_justica as in28_6_, processotr1_.in_selecionado_julgamento as in29_6_, processotr1_.in_selecionado_pauta
[pgbr-geral] WEBINAR DEXTRA: PostgreSQL 9.4: O que há de novo?
Pessoal, Hoje, logo mais, teremos um webinar sobre as novidades do PostgreSQL 9.4 com o grande Matheus Espanhol: Data: 05/MARÇO Horário: 11:30hr ASSISTA 'AO VIVO' VIA HANGOUT https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [1] Os webinares da Dextra utilizam a ferramenta Hangout On Air do Google http://www.google.com/+/learnmore/hangouts/?utm_source=Webinars+Dextrautm_campaign=982ae60119-Dextra+%7C+Webinars+2015+-+%C3%89+amanh%C3%A3+-+05marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [2]. Contamos com a participação de vocês! Ah! E fiquem de olho, a Dextra está sempre com vários webinares sobre tecnologia http://www.dextra.com.br/evento/webinar/. [1] https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [2] http://www.google.com/+/learnmore/hangouts/?utm_source=Webinars+Dextrautm_campaign=982ae60119-Dextra+%7C+Webinars+2015+-+%C3%89+amanh%C3%A3+-+05marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [3] http://www.dextra.com.br/evento/webinar/ PS: Peço desculpas por eventuais duplicatas dessa mensagem e pela demora, parece que a lista estava com alguns problemas. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] WEBINAR DEXTRA: PostgreSQL 9.4: O que há de novo?
Pessoal, Hoje, logo mais, teremos um webinar sobre as novidades do PostgreSQL 9.4 com o grande Matheus Espanhol: Data: 05/MARÇO Horário: 11:30hr ASSISTA 'AO VIVO' VIA HANGOUT https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [1] Os webinares da Dextra utilizam a ferramenta Hangout On Air do Google http://www.google.com/+/learnmore/hangouts/?utm_source=Webinars+Dextrautm_campaign=982ae60119-Dextra+%7C+Webinars+2015+-+%C3%89+amanh%C3%A3+-+05marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [2]. Contamos com a participação de vocês! Ah! E fiquem de olho, a Dextra está sempre com vários webinares sobre tecnologia http://www.dextra.com.br/evento/webinar/. [1] https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [2] http://www.google.com/+/learnmore/hangouts/?utm_source=Webinars+Dextrautm_campaign=982ae60119-Dextra+%7C+Webinars+2015+-+%C3%89+amanh%C3%A3+-+05marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [3] http://www.dextra.com.br/evento/webinar/ Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Video do Programa de Índio PostgreSQL 9.4: o que vem por aí
Senhores, para quem não pode ver ao vivo, está disponível para quem quiser conhecer o primeiro programa gravado ao vivo da Timbira: https://www.youtube.com/watch?v=UoO9g3shppw Comentários e sugestões para os próximos são bem vindos. Em abril deveremos fazer um programa só sobre o Jasonb. -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/s http://tellesr.wordpress.com/avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Stream Replication x Slony
Boa Tarde Comunidade, Atualmente estou usando o postgres 9.3.5, e estudando uma solução que sejá mais adequada para a minha realidade. Tenho um Server com vários databases, e gostaria de criar um slave para ter a replicação de alguns destes, não todos. Pelo que já li, através do Streaming replication, só consigo fazer a replicação de todos os databases, isso procede? Este seria um fator decisivo para que eu venha a fazer a minha replicação com Slony? Sobre a experiência de vocês com Slony, algo de negativo que vocês possam repassar? Grato desde já pela colaboração. -- Atenciosamente Francisco Porfirio Ribeiro Neto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Consulta não está utilizando índice
Bom dia. Estou com um problema e não sei o que está causando este. Ao executar a seguinte consulta : SELECT max( cd_cliente ) FROM cliente WHERE cd_filial_inclusao = 563 O resultado do plano de acesso é o seguinte: Result (cost=29.31..29.32 rows=1 width=0) (actual time=291588.847..291588.847 rows=1 loops=1) Output: $0 Buffers: shared hit=323106 read=1181788 InitPlan 1 (returns $0) - Limit (cost=0.43..29.31 rows=1 width=12) (actual time=291588.840..291588.840 rows=1 loops=1) Output: ((cliente.cd_cliente)::text) Buffers: shared hit=323106 read=1181788 - Index Scan Backward using pk_cliente on cliente (cost=0.43..377539.21 rows=13071 width=12) (actual time=291588.837..291588.837 rows=1 loops=1) Output: cliente.cd_cliente Index Cond: ((cliente.cd_cliente)::text IS NOT NULL) Filter: (cliente.cd_filial_inclusao = 563) Rows Removed by Filter: 1738205 Buffers: shared hit=323106 read=1181788 Planning time: 0.340 ms Execution time: 291588.916 ms 1 rows returned (execution time: 11,466 sec; total time: 11,498 sec) A tabela em questão ( cliente ), tem 2.435.230 linhas com 341 ( cd_filial_inclusao ) diferentes. Um dos índices da tabela é composto por cd_filial_inclusao, dh_inclusao. CREATE INDEX idx_cliente_inclusao ON cliente USING btree (cd_filial_inclusao, dh_inclusao); Neste caso a consulta não deveria utilizar o índice acima para realizar a busca? Pois até onde tenho conhecimento, ainda que um índice seja composto, se eu utilizar as colunas na ordem do índice na cláusula where, ainda que não utilize todas as colunas que compõe o índice, a busca deveria utilizar ele. SO: Windows 7 de 64 bits POSTGRESQL: PostgreSQL 9.4.0, compiled by Visual C++ build 1800, 64-bit Também testado na versão: PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit onde o resultado foi o mesmo. Agradeço antecipadamente as ajudas. Fernando Luís Cambiaghi *cambia...@gmail.com cambia...@gmail.com* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Retorno da Função
Criei uma função que faz um INSERT e retorna TRUE caso a transação tenha sucesso. CREATE OR REPLACE FUNCTION core.funcInsertBairros(f_nome character varying) RETURNS boolean AS $BODY$BEGIN INSERT INTO core.Bairros(nome) VALUES($1); -- Insert new Bairro RETURN TRUE; EXCEPTION WHEN NOT_NULL_VIOLATION THEN RAISE NOTICE 'Required filds are blank'; RETURN FALSE; WHEN RESTRICT_VIOLATION THEN RAISE NOTICE 'One or more restricts were violated'; RETURN FALSE; END;$BODY$ LANGUAGE plpgsql VOLATILE COST 100; A função faz o insert e termina normalmente, mas o retorno TRUE não aparece na aba [Data Output] do pgAdminIII Imagem: http://oi58.tinypic.com/bhkf2x.jpg ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Stream Replication x Slony
On 04-03-2015 16:08, Francisco Porfirio wrote: Atualmente estou usando o postgres 9.3.5, e estudando uma solução que sejá mais adequada para a minha realidade. Tenho um Server com vários databases, e gostaria de criar um slave para ter a replicação de alguns destes, não todos. Pelo que já li, através do Streaming replication, só consigo fazer a replicação de todos os databases, isso procede? Sim. Este seria um fator decisivo para que eu venha a fazer a minha replicação com Slony? Sobre a experiência de vocês com Slony, algo de negativo que vocês possam repassar? É um software maduro. Vale ressaltar que: * não replica DDLs automaticamente; * não replica large objects automaticamente; * não replica alteração em roles; * replicação com gatilhos pode ser tornar um gargalo se houver uma quantidade muito grande de servidores/bancos de dados/tabelas. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] WEBINAR DEXTRA: PostgreSQL 9.4: O que há de novo?
Em 5 de março de 2015 10:33, Matheus de Oliveira matioli.math...@gmail.com escreveu: Pessoal, Hoje, logo mais, teremos um webinar sobre as novidades do PostgreSQL 9.4 com o grande Matheus Espanhol: Data: 05/MARÇO Horário: 11:30hr ASSISTA 'AO VIVO' VIA HANGOUT https://plus.google.com/events/ce5ivddq8ok7vjvrddnucj9nr2k?utm_source=Webinars%20Dextrautm_campaign=982ae60119-Dextra%20%7C%20Webinars%202015%20-%20%C3%89%20amanh%C3%A3%20-%2005marutm_medium=emailutm_term=0_cda929bd6b-982ae60119- [1] Excelente! Obrigada por compartilhar! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
On 05-03-2015 10:28, Fernando Cambiaghi wrote: Neste caso a consulta não deveria utilizar o índice acima para realizar a busca? Pois até onde tenho conhecimento, ainda que um índice seja composto, se eu utilizar as colunas na ordem do índice na cláusula where, ainda que não utilize todas as colunas que compõe o índice, a busca deveria utilizar ele. ... se tiver uma seletividade grande. Olhando o seu plano temos: Rows Removed by Filter: 1738205 ou seja, o cd_filial_inclusao está presente em: (2.435.230 - 1.738.205) / 2.435.230 = 28.6% ... que é uma seletividade baixa. Talvez por isso ele não tenha usado o seu índice. cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? Você tentou fazer um ANALYZE na tabela cliente antes da consulta. Teve outro resultado? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
