Re: [pgbr-geral] Erro ao reiniciar banco
Você mandou o log do encerramento. Ele é absolutamente normal. O FATAL que aparece é a mensagem enviada a uma das conexões pra avisá-la que o banco foi encerrado no modo fast (cancelam-se as transações em andamento e encerram-se a força as conexões). Poderia nos mandar as mensagens que aparecem ao fazer, por exemplo? service postgresql start Qual o seu S.O. e versão, além do PostgreSQL? Suponho que seja CentOS ou Fedora. Como foi instalado? Pacotes da distro, repositório PGDG, instalador da EnterpriseDB? []s Flavio Gurgel Flavio, estamos usando CentOS 6.3, PostgreSQL 9.1 instalado via repositorio PGDG. O comando service postgresql start mostra a mensagem the database system is shutting down. ___ 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 reiniciar banco
Glauco, Quando você utiliza o service postgresql start ele no log esta apresentando the database system is shutting down? Sim. == Seu banco nesse momento esta OK? Nao, quando a aplicacao tenta conectar, aparece a mesma mensagem de erro. Assim como o Flavio já te passou esse log que vc esta vendo é somente do shutting down do start ou ele não esta pegando ou esta tendo algum problema para subir seu banco, esse log você esta pegando de onde? Da pasta pg_log.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro ao reiniciar banco
Pessoal, hoje, houve uma tentativa de reiniciar o banco atraves do comando service postgresql restart, o banco parou e nao subiu mais, conforme log abaixo: LOG: terminating walsender process due to replication timeout LOG: received fast shutdown request LOG: aborting any active transactions FATAL: terminating connection due to administrator command FATAL: the database system is shutting down So consegui subir o banco, apos reiniciar o Linux. Duvida: Por que este erro aconteceu ? Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] update em valores que ja existem
Pessoal, duvida: No comando abaixo estou alterado o campo1 para um valor que ja existe, neste caso o PostgreSQL ignora ou faz as alteracoes em disco ? UPDATE tabela SET campo1 = 0 WHERE campo1 = 0; É uma boa pratica comparar os valores, conforme exemplo abaixo ? UPDATE tabela SET campo1 = 1, campo2 = 2, campo3 = 3 WHERE campo1 1 OR campo2 2 OR campo3 3; Desde ja, agradeço. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro deadLock
Pessoal, o que significa o erro abaixo e o que fazer para evita-lo ? PGRES_FATAL_ERROR - ERROR: deadlock detected DETAIL: Process 16306 waits for ShareLock on transaction 110599693 blocked by process 16294. Process 16294 waits for ShareLock on transaction 110599686 blocked by process 16306. SQL Statement: Update ... PL/pgSQL function Ambiente: PostgreSQL 9.1.4 Centos 6.3 Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Nomes iguais de campos no select
Pessoal, uma duvida: Por que o select abaixo, com campos de nomes iguais, nao gera erro ? SELECT campo1, 0::INT AS campo1 FROM tabela Desde ja, agradeço. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Select de todas as colunas menos 1
Pessoal, uma duvida de principiante: É possivel selecionar todos os campos de uma tabela ou subselect, ignorando um ou mais campos ? Exemplo: SELECT * except campo5 FROM tabela Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] SubSelect em Window Function
Pessoal, existe possibilidade de transformar o SubSelect abaixo em Window Function ? SELECT campo1, (SELECT campo1 FROM tabela2 GROUP BY campo1 ORDER BY count(campo1) DESC LIMIT 1) as subselect FROM tabela1 Neste SubSelect estou buscando em uma outra tabela o registro que contem mais ocorrencias. obrigado, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SubSelect em Window Function
Eu não entendi a consulta e nem a sua descrição. Dá para ser mais específico? Existe campo1 na tabela1 e tabela2? Qual é a relação da tabela1 com a tabela2? Euler, realmente me equivoquei, a intencao era mostrar o subselect na mesma tabela. Exemplo: Tenho que buscar em uma tabela temporaria o pedido e o motivo principal de rejeicao dos itens. PEDIDO | OCORRENCIA - 12345 | SEM ESTOQUE 12345 | SEM ESTOQUE 12345 | SEM CADASTRO Consulta: SELECT pedido, ocorrencia as rejeicao, count(1) FROM temp GROUP BY 1,2 ORDER BY 3 DESC LIMIT 1; Resultado: PEDIDO | OCORRENCIA - 12345 | SEM ESTOQUE Seria possivel usar Window Function neste caso ? Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Importacao de arquivos XML
Pessoal, como faço para importar um aquivo XML para uma tabela no PostgreSQL 9.1 ? Alguem teria um exemplo ? Gostaria de importar alguns arquivos e buscar os valores de algumas tags. Eu li a documentacao, mas nao consegui entender a sintaxe. Desde ja, agradeço. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] duvida com indice em campo booleano
Pessoal, em uma tabela foi criado um indice assim: campo = false. Quando eu rodo a consulta selecionando campo is false, o indice nao é utilizado. O indice so é utilizado se seleciono campo = false. Alguem saberia me explicar por que isso acontece ? Desde ja, agradeço. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Controle de versao dos dados
Pessoal, estou implantando um FDW que busca dados de uma tabela no SQL Server 2005 e salva em uma tabela do PostgreSQL 9.1. Eu consegui fazer buscar os novos registros e salva-los, mas estou com dificuldade em identificar o que foi alterado e excluido na tabela remota. Como eu poderia implantar um controle de versao (ou um historico) desses registros no PostgreSQL ? Vou ter que consultar a tabela remota inteira toda vez ? Qual a melhor forma de manter os dados remotos sincronizados na tabela local ? Se alguem tiver alguma dica, desde ja agradeco. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida com Vacuum Full
Boa noite pessoal, tenho uma duvida: É possivel identificar quais tabelas do banco estao inchadas, ou seja, que sofreram muitas alteracoes e que necessitam de vacuum full ? Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvida em escrita de SQL
Pessoal gostaria de uma dica dos mais esperientes: Qual a diferença para o banco na escrita destes dois SQLs? SELECT twe.* , (SELECT descricao FROM tespecializacoes WHERE idespecializacao = twe.idespecializacao) AS especializacao FROM tworkflowetapas twe SELECT twe.* FROM tworkflowetapas twe LEFT JOIN tespecializacoes esp ON (twe.idespecializacao = esp.idespecializacao) Tem alguma diferença de performance, quebra de indices, etc? Acredito que o LEFT JOIN valeria a pena se fosse para buscar 2 ou mais campos na tabela tespecializacoes, o SQL abaixo seria menos performatico, ou estou errado ? SELECT twe.* , (SELECT descricao FROM tespecializacoes WHERE idespecializacao = twe.idespecializacao) AS especializacao, , (SELECT outro_campo FROM tespecializacoes WHERE idespecializacao = twe.idespecializacao) AS exemplo FROM tworkflowetapas twe ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Lentidao em consulta usando Between com datas iguais
Pessoal, gostaria de comentar uma situacao, aqui na empresa tem um relatorio que o usuario fornece as datas inicial e final para gerar os dados, quando as datas sao iguais a consulta no banco de dados demora mais tempo que o normal, entre datas diferentes a consulta é feita rapidamente. No teste que fiz percebi o seguinte: Se eu coloco campo = data a consulta executa normalmente, mas se eu coloco campo BETWEEN data AND mesmadata a consulta demora muito mais tempo. Utilizamos a versao 9.1 com Linux CentOS. Se alguem tiver alguma dica, agradeco. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida sobre schema em funcao
Pessoal, quando eu executo o comando SET search_path TO nome_schema dentro de uma funcao, em uma mesma sessao, o SGDB nao altera o search_path nos comandos executados apos o primeiro, me parece que o schema fica em um tipo de cache. Duvida: Existe alguma forma de contornar isso? Sei que posso usar o comando Execute passando o schema em uma variavel, mas gostaria de evitar fazer comandos sql concatenando Strings. Desde ja, agradeco. Wellington ___ 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 resolver alta demanda de conexoes
Em 30 de janeiro de 2014 15:02, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Mais uma dúvida, estamos com o Postgres rodando em uma máquina virtual, teríamos mais desempenho se estivéssemos rodando em uma máquina física com as mesmas configurações? Não sequestre a thread. Isso é outro assunto, não relacionado à sua primeira pergunta. Todavia, a resposta é *depende*. Hoje pode-se fazer ótimos servidores de bancos de dados virtuais, principalmente com umas máquinas gigantes que andam vendendo por aí (centenas de CPUs e terabytes de memória). Pra fazer uma cola com o assunto origila, isso não muda o fato de que você está abrindo conexões demais ao banco. Físico ou virtual, é conexão demais. Você tem a faca (PgBouncer) e o queijo (PostgreSQL) na mão. É só cortar (diminuir o número de conexões ao banco, nas configurações do PgBouncer). E conte pra nós seu sucesso daqui a pouco. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Olá colegas, depois de vários testes, deixamos o PgBoucer passando 22 conexões para o PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um pouco lenta. Abs. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como resolver alta demanda de conexoes
Bom dia pessoal, Temos o seguinte cenário: Durante 2 semanas por ano nosso sistema sofre uma alta demanda de acessos. São 6000 usuários em potencial. De acordo com nosso analista de infra, na última matrícula o postgreSQL foi derrubado por 450 usuários concorrentes. Estamos montando um ambiente PostgreSQL para atender esta demanda. É uma máquina virtual com 32 núcleos e 24GB de Ram. PostgreSQL 9.3 e com PGBouncer. O sistema é PHP/WEB e está sendo montado com 6 máquinas Apache para atender os usuários em potencial. O banco de dados é pequeno, tem 2GB, mas o sistema posssui consultas muito pesadas. Configuramos o PostgreSQL com max_connection de 250. O PGBouncer está recebendo até 2 e passando para o postgres 240. Estamos rodando testes de carga com o JMeter e com 500 usuários o sistema fica muito lento, ocorre erros de conexão(o log do PGbouncer apresenta Could not connect), os 32 núcleos atingem 100% de uso. O que estamos errando na nossa configuração? Abs. Wellington ___ 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 resolver alta demanda de conexoes
Nós monitoramos o uso de I/O e CPU e não temos problema de disco (Raid 10 em SSD) e a rede é GB. Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: checkpoint_segments = 8 # pgtune wizard 2014-01-29 maintenance_work_mem = 1GB # pgtune wizard 2014-01-29 effective_cache_size = 16GB # pgtune wizard 2014-01-29 work_mem = 20MB # pgtune wizard 2014-01-29 wal_buffers = 4MB # pgtune wizard 2014-01-29 shared_buffers = 5632MB # pgtune wizard 2014-01-29 max_connections = 250 # pgtune wizard 2014-01-29 Qto aos logs, só estamos logando erros. PgBouncer: pool_mode = session server_check_delay = 10 max_client_conn = 2 default_pool_size = 250 server_idle_timeout = 300 Sobre as consultas, são Stored Procedures complexas(que às vezes umas chamam outras) que encapsulam muitas regras de negócio, requerendo muita análise para serem alteradas. Em 30 de janeiro de 2014 09:59, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 30 de janeiro de 2014 09:50, Wellington Openheimer wopenhei...@gmail.com escreveu: Bom dia pessoal, Temos o seguinte cenário: Durante 2 semanas por ano nosso sistema sofre uma alta demanda de acessos. São 6000 usuários em potencial. De acordo com nosso analista de infra, na última matrícula o postgreSQL foi derrubado por 450 usuários concorrentes. Estamos montando um ambiente PostgreSQL para atender esta demanda. É uma máquina virtual com 32 núcleos e 24GB de Ram. PostgreSQL 9.3 e com PGBouncer. Como são os discos do servidor e como estão configurados? O sistema é PHP/WEB e está sendo montado com 6 máquinas Apache para atender os usuários em potencial. O banco de dados é pequeno, tem 2GB, mas o sistema posssui consultas muito pesadas. Não há nenhuma maneira de agilizar estas consultas? Uma ótima solução seria utilizar o explain pra verificar o plano de execução e otimizar estas consultas.. Se a base é pequena, consultas pesadas seriam meio alheias a este ambiente. Configuramos o PostgreSQL com max_connection de 250. O PGBouncer está recebendo até 2 e passando para o postgres 240. Como estão as outras configurações do PostgreSQL (work_mem, shared_buffers, effective_cache_size, ...)? Estamos rodando testes de carga com o JMeter e com 500 usuários o sistema fica muito lento, ocorre erros de conexão(o log do PGbouncer apresenta Could not connect), os 32 núcleos atingem 100% de uso. Acredito ser um ambiente consideravelmente pequeno pra ocorrer este tipo de problema. Provavelmente as respostas acima nos levarão a uma solução, acredito eu. O que estamos errando na nossa configuração? Abs. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ 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 resolver alta demanda de conexoes
Flávio, vc disse pra diminuir o max_connection e diminuir o Bouncer para 30. Vamos testar, mas como estamos testando com 500 no Jmeter, isso não vai gerar muita fila de espera, visto que as consultas são pesadas? Douglas No Postgre logou too many clients e foi resolvido com o Bouncer e deu erro de semáforos. Rafael, Quando rodamos os testes, percebemos que não consome memória(não faz Swap), mas sim CPU's, que colam 100%. Em 30 de janeiro de 2014 11:17, Rafael Fialho Corrêa r.fia...@ibest.com.brescreveu: Em 30 de janeiro de 2014 10:41, Wellington Oppenheimer welling...@unifei.edu.br escreveu: Nós monitoramos o uso de I/O e CPU e não temos problema de disco (Raid 10 em SSD) e a rede é GB. Para as configurações do Postgres utilizando o Pgtune para 250 usuários. Estão assim: checkpoint_segments = 8 # pgtune wizard 2014-01-29 maintenance_work_mem = 1GB # pgtune wizard 2014-01-29 effective_cache_size = 16GB # pgtune wizard 2014-01-29 work_mem = 20MB # pgtune wizard 2014-01-29 wal_buffers = 4MB # pgtune wizard 2014-01-29 shared_buffers = 5632MB # pgtune wizard 2014-01-29 max_connections = 250 # pgtune wizard 2014-01-29 Bom.. imaginando uma situação surreal onde entendamos todo o seu ambiente, que deve ser bem mais complexo do que entendemos até aqui, vamos lá. Com essas configurações e apenas 24GB de RAM, creio que os erros com 500 usuários simultâneos são quase obrigação no caso de overcommit da memória.. Visto que sua base é pequena e considerando não haver problemas de I/O, no caso de demora e crash nas consultas eu faria as seguintes alterações em via de testes: - maintenance_work_mem = 256MB - wal_buffers = manter padrão - checkpoint_timeout = 30min - work_mem = 4MB - shared_buffers = 3072MB ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida sobre sequence
Pessoal, tenho uma duvida: Eh possivel fazer uma consulta das sequencias que nao estao sendo utilizadas em nenhuma tabela ? Pelo que percebi, ao excluir uma tabela, a sequencia associada a ela nao é excluida. Desde ja, agradeco. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvidas em consultas
Pessoal, tenho 2 duvidas. - Considerando a consulta abaixo: SELECT * FROM tabela1 JOIN tabela2 ON tabela2.idcliente = tabela2.idcidade; No exemplo acima ha um erro no JOIN em que a tabela2 esta referenciando a ela mesma, pergunto: Por que o PostgreSQL executa normalmente essa consulta sem acusar erros? - Na consulta abaixo: select 15.5 / (4/9); o PostgreSQL acusa erro de divisao por zero, mas se eu fizer essa alteracao select 15.5 / (4/9.0); a consulta roda normalmente, por que isso acontece? desde ja agradeco, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] duvidas sobre replicacao por streaming
Pessoal, boa tarde a todos, tenho uma duvida: Por que ao fazer uma consulta sql em um servidor Slave, as vezes o PostgreSQL cancela as consultas ? O erro mostrado eh o seguinte: Comando cancelado devido a conflitos de recuperacao. Outra duvida: Existe algum processo automatico que verifica se o servidor slave esta com os dados sincronizados com o servidor master ? Desde ja agradeço. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] duvidas sobre replicacao por streaming
- Original Message - From: Matheus de Oliveira To: Comunidade PostgreSQL Brasileira Sent: Tuesday, November 05, 2013 1:34 PM Subject: Re: [pgbr-geral] duvidas sobre replicacao por streaming 2013/11/5 Wellington wm...@yahoo.com.br Pessoal, boa tarde a todos, tenho uma duvida: Por que ao fazer uma consulta sql em um servidor Slave, as vezes o PostgreSQL cancela as consultas ? O erro mostrado eh o seguinte: Comando cancelado devido a conflitos de recuperacao. Isso ocorre devido à um conflito com o que está sendo replicado (enviado pelo master) e o que está sendo consultado no slave. Por exemplo (bem superficial), vamos pensar que o autovacuum removeu a tupla X no master, quando essa informação é enviada para o slave, o mesmo deve removê-la também, mas pode ser que alguma consulta esteja lendo ela (ela está visível à transação), logo o slave não pode remover, ou seja, houve um conflito entre um comando executando no slave e o enviado pelo walsender do master. Soluções, vão depender da sua versão do PostgreSQL e uma análise mais detalhada. Matheus, acho que os conflitos estao acontecendo entao, por causa da remoçao de tuplas que os proprios usuarios fazem. O autovacuum esta desabilitado, pois é executado em horarios agendados no cron. Outra duvida: Existe algum processo automatico que verifica se o servidor slave esta com os dados sincronizados com o servidor master ? Sim. Também vai depender de sua versão do PostgreSQL. A gente usa a versao 9.1, existe algo referente a isto nas versoes mais novas ? 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] [OFF TOPIC] - TCC sobre PostgreSQL
Pessoal, boa noite, estou concluindo meu TCC, que trata sobre algumas funcionalidades do PostgreSQL. Gostaria, se possivel, da opiniao de algum especialista sobre o trabalho que elaborei e quem sabe, receber dicas de como poder melhora-lo. Quem tiver disponibilidade, contate-me em PVT. Obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Servidor HTTPS lentidão em consultas POSTGRESQL
Olá pessoal, Minha dúvida não está totalmente ligada às consultas de bancos de dados, mas no protocolo do servidor web. Estamos estudando passar um sistema inteiro para HTTPS e pelo que estudamos isto afetaria a performance da aplicação. Temos tarefas e consultas complexas e em torno de 1 usuários potenciais. De acordo com a experiência de vocês, servidores web com HTTPS deixaram as aplicações mais lentas(consultas, etc.)? Alguma configuração em específico que devemos olhar? Obs.: Rodamos em PHP+Apache Desde já obrigado pessoal. att, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro ao restaurar base
Pessoal, bom dia, surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. Utilizamos CentOS versao 6 64bits. Estou usando o PGAdmin versao 1.12, que usei a um tempo atras para fazer o dump; agora quando tento fazer o restore aparecem os erros abaixo: ERROR: parameter standard_conforming_strings cannot be changed ERROR: syntax error at or near PROCEDURAL at character 19 ERROR: relation dblink_pkey_results already exists ERROR: could not find function dblink_cancel_query in file /usr/lib64/pgsql/dblink.so tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: ERROR: could not load library /usr/lib64/pgsql/dblink.so: /usr/lib64/pgsql/dblink.so: undefined symbol: SnapshotNowData Alguem tem ideia do por que acontecem os erros? desde ja agradeço, Wellington ___ 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 restaurar base
- Original Message - From: Flavio Henrique Araque Gurgel fla...@4linux.com.br To: pgbr-geral@listas.postgresql.org.br Sent: Tuesday, August 20, 2013 11:30 AM Subject: Re: [pgbr-geral] Erro ao restaurar base Em 20-08-2013 11:17, Wellington escreveu: Pessoal, bom dia, surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. Utilizamos CentOS versao 6 64bits. Estou usando o PGAdmin versao 1.12, que usei a um tempo atras para fazer o dump; agora quando tento fazer o restore aparecem os erros abaixo: Use a versão mais nova do PgAdmin, 1.16 ERROR: parameter standard_conforming_strings cannot be changed Você está tentando essa restauração na versão 8.1 (você não disse, estou chutando), então, essa configuração não está disponível via SQL. Ignore este erro. ERROR: syntax error at or near PROCEDURAL at character 19 Passe a linha inteira dentro desse dump, onde deu esse erro. Quem gerou esse dump colocou uma palavra que não existina na versão 8.1 ERROR: relation dblink_pkey_results already exists Estranho. O dump foi gerado errado. ERROR: could not find function dblink_cancel_query in file /usr/lib64/pgsql/dblink.so Foi usada uma biblioteca dblink no banco antigo diferente da atual. tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: Ah, bem melhor fazer assim. Vá logo pra 9.2, não se arrependerá. ERROR: could not load library /usr/lib64/pgsql/dblink.so: /usr/lib64/pgsql/dblink.so: undefined symbol: SnapshotNowData Instale o dblink. Tá faltando. Não sei como você instalou o PostgreSQL, então, fica difícil dar a dica de como instalar. Alguem tem ideia do por que acontecem os erros? Bom, taí. Passe mais informações conforme pedido pra continuarmos. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS Flavio, realmente faltou uma linha do erro: ERROR: syntax error at or near PROCEDURAL at character 19 language plpgsql does not exist O aplicativo é de terceiros e foi descontinuado. Antes eu instalava a versao 8.1 pelo yum e o aplicativo carregava normalmente, mas agora os repositorios dessa versao nao estao mais ativos, entao eu instalei pelos pacotes rpm; devo ter feito algo errado; eu instalei os pacotes postgresql81, postgresql81-libs, postgresql81-server e postgresql81-contrib. Com esses erros do restore, o aplicativo nao inicializa. Estou tentando restaurar na base da versao 8.1. Att, Wellington ___ 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] could not fork new process for connection: Resource temporarily unavailable. O que é isso pessoal?
Pessoal, Agradeço a todos que colaboraram na resolução do meu problema. Realmente, quem salvou a gente aqui foi o PGBOUNCER. Ativamos no servidor e o sistema voltou. Respondendo sobre o sistema, o sistema é web sim. A cada requisição nós abrimos e fechamos a conexão com o banco. Ontem tínhamos 6000 usuários potenciais que estavam acessando o sistema no mesmo instante. É complicado, pois o nosso sistema aqui funciona como se fosse um ítem na promoção que todo mundo quer concorrer para conseguir comprar. Todo mundo entra ao mesmo tempo. O PGBouncer salvou nossa pele e tudo correu bem. Mais uma vez, obrigado a todos colegas que cooperaram. att, Wellington Em 31 de julho de 2013 13:50, JotaComm jota.c...@gmail.com escreveu: Opa, Em 31 de julho de 2013 13:34, Euler Taveira eu...@timbira.com.brescreveu: On 31-07-2013 13:05, Wellington Oppenheimer wrote: Tem 6000 pessoas acessando o sistema. O max_connections está em 1950. E qual o hardware utilizado? Como disse o Fabio, você está *desperdiçando* recursos. Considere utilizar um pool de conexões. Deixa eu adivinhar... aplicações web? Nessas condições, como deve ficar o /etc/security/limits.conf ? Seria melhor você mostrá-lo (sem os comentários), não? Ao colocar um max_connections = 1950 você está nos dizendo que você tem 1950 acessos simultâneos ao seu banco. Você tem certeza disso? Como o Telles e o Euler já citaram, você pode pensar em um pgpool [1] ou pgbouncer [2]. Agora com relação a mensagem: Error connecting to the server: could not fork new process for connection: Resource temporarily unavailable. Ela significa que o SO não consegue mais criar processos (fork), para resolver isso você precisar modificar o parâmetro nproc [3]. [1] http://www.pgpool.net/mediawiki/index.php/Main_Page [2] http://pgbouncer.projects.pgfoundry.org/ [3] http://linux.die.net/man/5/limits.conf -- 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 Abraços -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] [PROBLEMA] could not fork new process for connection: Resource temporarily unavailable. O que é isso pessoal?
Pessoal, O sistema aqui recebeu um grande de número de acesso de pessoas e travou completamente com esta mensagem: Error connecting to the server: could not fork new process for connection: Resource temporarily unavailable O que pode ser isso? Tá muito crítica a situação aqui. Quem puder me ajudar eu agradeço. Wellington ___ 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] could not fork new process for connection: Resource temporarily unavailable. O que é isso pessoal?
Tem 6000 pessoas acessando o sistema. O max_connections está em 1950. Nessas condições, como deve ficar o /etc/security/limits.conf ? O banco não volta de jeito nenhum...tenso demais Em 31 de julho de 2013 12:30, Euler Taveira eu...@timbira.com.br escreveu: On 31-07-2013 12:19, Wellington Openheimer wrote: O sistema aqui recebeu um grande de número de acesso de pessoas e travou completamente com esta mensagem: Quanto é grande? Chegou próximo ao max_connections? Existem outras mensagens de erro anteriores a essa e que estejam relacionadas? Error connecting to the server: could not fork new process for connection: Resource temporarily unavailable O Postgres não consegue mais abrir conexões por falta de recursos. Se a máquina não estiver esgotada possivelmente há um limite estabelecido (se for Linux, em /etc/security/limits.conf procure por nproc). Informe melhor o cenário para podermos ter uma pista. -- 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 -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ 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] could not fork new process for connection: Resource temporarily unavailable. O que é isso pessoal?
devo mudar o max_connections para 6000? Em 31 de julho de 2013 13:06, Osvaldo Kussama osvaldo.kuss...@gmail.comescreveu: Em 31/07/13, Wellington Openheimerwopenhei...@gmail.com escreveu: Pessoal, O sistema aqui recebeu um grande de número de acesso de pessoas e travou completamente com esta mensagem: Error connecting to the server: could not fork new process for connection: Resource temporarily unavailable O que pode ser isso? Tá muito crítica a situação aqui. Quem puder me ajudar eu agradeço. Seu sistema não tem recursos suficientes para criar o processo que atenderia a nova conexão solicitada. Estime melhor a quantidade máxima de conexões possíveis considerando os recursos de sua máquina. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Quando usar VACUUM, ANALYZE e REINDEX
Pessoal, Tenho uma tabela crítica no sistema, que daqui há alguns dias ela irá sofrer um grande número de transações(inserções, update e delete) Estou na dúvida se rodo agora ANALYZE, VACUUM FULL e REINDEX. Na verdade estou mais em dúvida do REINDEX. Além da chave primária, esta tabela tem mais 2 índices. Conto com a ajuda de vocês...no sábado a tabela já entra em produção novamente... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar VACUUM, ANALYZE e REINDEX
Olá Flávio, Este é o resultado para a tabela que estou me referindo. Detalhe, estas linhas foram as primeiras da consulta. schemaname tablename tbloat wastedbytes iname ibloat wastedibytes public tb_matricula 1.3 34873344 turmateo_idx 0.4 0 public tb_matricula 1.3 34873344 pk_tb_matricula 0.6 0 public tb_matricula 1.3 34873344 turmapra_idx 0.4 0 Em 18 de julho de 2013 11:55, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: - Mensagem original - Pessoal, Tenho uma tabela crítica no sistema, que daqui há alguns dias ela irá sofrer um grande número de transações(inserções, update e delete) Estou na dúvida se rodo agora ANALYZE, VACUUM FULL e REINDEX. Na verdade estou mais em dúvida do REINDEX. Além da chave primária, esta tabela tem mais 2 índices. Conto com a ajuda de vocês...no sábado a tabela já entra em produção novamente... Não há nada a fazer sem saber o estado da tabela e seus índices. Já executou a consulta de inchaço para ver o estado dela e seus índices? http://wiki.postgresql.org/wiki/Show_database_bloat A consulta é *gigante* mas não se preocupe, ela executa rapidinho e pega só dados do catálogo do PostgreSQL. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quando usar VACUUM, ANALYZE e REINDEX
Entendi, e nesse caso aqui: schemaname tablename tbloat wastedbytes iname ibloat wastedibytes public tb_discavlnotas 1.2 11730944 pk_tb_discavlnotas 1.4 16588800 O que significa? A diferença pelo que vi é a coluna wastedibytes. Em 18 de julho de 2013 12:30, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Este é o resultado para a tabela que estou me referindo. Detalhe, estas linhas foram as primeiras da consulta. Evite o top-post. schemaname tablename tbloat wastedbytes iname ibloat wastedibytes public tb_matricula1.3 34873344turmateo_idx 0.4 0 public tb_matricula1.3 34873344pk_tb_matricula 0.6 0 public tb_matricula1.3 34873344turmapra_idx 0.4 0 Não me parece ter muito a fazer nessa tabela nem seus índices. Inchaço normal para uma tabela em modo OLTP (considerando o que você disse). Qual a versão de seu PostgreSQL? Se você tiver tempo e quiser uma tabela limpinha, você pode considerar um VACUUM FULL seguido de REINDEX TABLE. Caso seu PostgreSQL seja mais antigo que 9.0, troque o VACUUM FULL por um CLUSTER. Mas, na boa, eu não faria *nada*, exceto se o espaço ocupado por ela em disco for muito grande, informação esta que você não passou. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- *Wellington Openheimer Ribeiro* Analista de Tecnologia da Informação *UNIFEI - Universidade Federal de Itajubá* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comando Delete retorna 0 rows affected mesmo com dados para serem deletados
Olá pessoal, Tenho o seguinte problema: Faço um select na tabela B na qual retorna dados. Depois faço um delete e retorna 0 rows affected. Refaço o select e os dados ainda estão lá. Caso: A tabela B possui chave estrangeira para a tabela A. Esta chave está ON DELETE CASCADE. Mas a tabela B possui uma Trigger BEFORE DELETE, na qual não deixa deletar por um determinado motivo. Olha que estranho, esse dado que estou tentando deletar não está na tabela A(chave). Concluí que houve um delete na tabela A que não conseguiu deletar por cascata na tabela B e agora travou os dados na tabela B. Como resolvo isso? esse problema tá gerando um transtorno enorme para nós aqui... Um abraço a todos. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] reindex apos vacuum full
Pessoal, ha informacoes na internet, de que apos a versao 9 nao eh mais necessario executar o reindex database apos o vacuum full, mas nao encontrei nada na documentacao que confirmasse isso. Essa informacao procede? desde ja, obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES
Oi Flavio,
Realmente é estranho. Analisando o explain parece que não dá diferença, mas
quando o rodo o programa específico da uma diferença gritante. Tínhamos um
caso em que a consulta demorava 30 segundos e depois destes 2 índices caiu
pra 6 segundos. Estamos com c=medo é dos inserts que rodam junto com as
consultas, se vão ficar lentos ou causar mais lentidão no sistema.
Se nós mantermos os índices podemos removê-los a qualquer momento com o
sistema em produção?
A nossa versão é a 9.1.7.
realmente é estranho...
Em 8 de fevereiro de 2013 23:28, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Essa é a chave da tabela:
pk_tb_matricula PRIMARY KEY(matr , cursocod , gradecod , disccodof ,
periodo
, ano );
Esses são os 2 índices que fizeram diferença na execução da consulta do
programa:
CREATE INDEX turma_teo
ON tb_matricula
USING btree
(turmateo COLLATE pg_catalog.default , ano , periodo );
CREATE INDEX turmapra_idx
ON tb_matricula
USING btree
(turmapra COLLATE pg_catalog.default , ano , periodo );
Esta é a consulta complicada:
O problema é que o programa faz um FOR nesta consulta, pois é um count de
cada turma.
explain analyze SELECT COUNT(*)
FROM TB_MATRICULA
WHERE DISCCODOF= 'ADM082' AND
LOCALCOD = 'C01' AND
((REGIME = 'A' AND ANO = 2012) OR
(REGIME !='A' AND ANO = 2012 AND PERIODO = 1)) AND
(TURMATEO = 'X') OR
('TURMAPRA = 'Y'));
Esse foi o resultado do Explain:
Aggregate (cost=4835.89..4835.90 rows=1 width=0) (actual
time=39.486..39.486
rows=1 loops=1)
- Index Scan using pk_tb_matricula on tb_matricula (cost=0.00..4835.02
rows=351 width=0) (actual time=0.190..39.231 rows=1520 loops=1)
Index Cond: (((disccodof)::text = 'ADM082'::text) AND (ano = 2012))
Filter: ((localcod = 'C01'::bpchar) AND (((turmateo)::text =
'1'::text) OR
((turmapra)::text = ''::text)) AND ((regime = 'A'::bpchar) OR ((regime
'A'::bpchar) AND (periodo = 1
Total runtime: 39.591 ms
Bom, veja seu plano de execução:
A consulta usou apenas o índice da chave primária (pg_tb_matricula).
A consulta levou pouco mais de 39 ms para executar, obteve uma linha
agregando 4835 (por causa do count) e fim, dentre
Portanto, os índices turmapra_idx e turma_teo, para essa consulta em
específico, não estão sendo utilizados.
Considere removê-los e veja se o plano de execução muda (faça outro
EXPLAIN ANALYZE sem os índices).
Se o plano *não* mudar (não deve mudar, porque o índice usado foi o da
pk), simplesmente fique sem os índices exceto a própria chave primária.
Claro que não estou considerando outras consultas que você pode ter em seu
sistema.
39 ms me parece um tempo excelente para execução de uma consulta com
count(*).
Você disse que faz um laço em seu programa (for) e executa a consulta
várias vezes. Quantas vezes?
Não dá pra trocar o laço por uma consulta mais elaborada e deixar o banco
de dados fazer isso por você?
Outra coisa interessante, qual versão do PostgreSQL está usando?
Na versão 9.2.x você tem o recurso index_only_scan que pode melhorar o
desempenho dessa consulta em umas... 10 ou 12 vezes. Não que você precise
disso, claro.
[]s
__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
*Wellington Openheimer Ribeiro*
Analista de Tecnologia da Informação
*UNIFEI - Universidade Federal de Itajubá*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida memoria ram
Pessoal, temos aqui na empresa um servidor com a seguinte configuracao: - postgresql 9.0 com base de dados de 45GB - duplo processador com 4 nucleos cada - 2 discos SAS em raid 1 com 146GB cada - 8GB memora ram Estamos pensando em fazer um upgrade na memoria ram, a duvida eh: Vale a pena investir em 64GB ou 32GB ja estaria de bom tamanho ? desde ja, obrigado. Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvida memoria ram
sim Itamar, a maquina esta com linux Centos, sistema de arquivos ext2. De uns tempos pra ca, algumas consultas passaram a ficar lentas, e ficam mais lentas quando aumenta o numero de usuarios conectados (em torno de 45). Percebi que essas consultas envolvem 2 tabelas com tamanho de 5GB cada. Estou executando o vacuum diariamente e o vacuum full semanal. Sera que com o aumento da memoria ram conseguirei eliminar esse gargalo ? Att. Wellington - Original Message - From: Itamar Reis Peixoto ita...@ispbrasil.com.br To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Sunday, February 10, 2013 12:32 AM Subject: Re: [pgbr-geral] Duvida memoria ram 2013/2/9 Wellington wm...@yahoo.com.br: Pessoal, temos aqui na empresa um servidor com a seguinte configuracao: - postgresql 9.0 com base de dados de 45GB - duplo processador com 4 nucleos cada - 2 discos SAS em raid 1 com 146GB cada - 8GB memora ram Estamos pensando em fazer um upgrade na memoria ram, a duvida eh: Vale a pena investir em 64GB ou 32GB ja estaria de bom tamanho ? desde ja, obrigado. Wellington esta tendo algum tipo de gargalo na maquina ? -- Itamar Reis Peixoto http://www.quebarato.com.br/perfil/itamarjp ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES
Olá pessoal, Temos uma tabela que em um determinado tempo ela é muito consultada e ao mesmo tempo sofre muitos inserts e updates. Acontece que a consulta é bem complexa e está ficando cada vez mais lenta com o aumento do número de dados. Decidimos então testar a criação de uns índices com os principais campos nas cláusulas WHERE das consultas mais lentas. A consulta ficou bem mais rápida, mas estamos receosos se estes índices irão deixar mais lenta a inserção e update de dados pois esses comandos teriam então que inserir no índice também. Obs.: Criamos 2 índices compostos btree. (campo1, campo2, campo3) (campo4, campo2, campo3) campo2 e campo3 fazem parte da chave da tabela que possui 5 campos chave. Detalhe: temos 2 consultas muito pesadas que usam no where campo1, campo2 e campo3 e campo4, campo2 e campo3 respectivamente. Seremos muito grato se puderem nos ajudar. att, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ÍNDICES EM TABELAS QUE RECEBEM MUITOS INSERTS, UPDATES
Olá Flávio,
Essa é a chave da tabela:
pk_tb_matricula PRIMARY KEY(matr , cursocod , gradecod , disccodof ,
periodo , ano );
Esses são os 2 índices que fizeram diferença na execução da consulta do
programa:
CREATE INDEX turma_teo
ON tb_matricula
USING btree
(turmateo COLLATE pg_catalog.default , ano , periodo );
CREATE INDEX turmapra_idx
ON tb_matricula
USING btree
(turmapra COLLATE pg_catalog.default , ano , periodo );
Esta é a consulta complicada:
O problema é que o programa faz um FOR nesta consulta, pois é um count de
cada turma.
explain analyze SELECT COUNT(*)
FROM TB_MATRICULA
WHERE DISCCODOF= 'ADM082' AND
LOCALCOD = 'C01' AND
((REGIME = 'A' AND ANO = 2012) OR
(REGIME !='A' AND ANO = 2012 AND PERIODO = 1)) AND
(TURMATEO = 'X') OR
('TURMAPRA = 'Y'));
Esse foi o resultado do Explain:
Aggregate (cost=4835.89..4835.90 rows=1 width=0) (actual
time=39.486..39.486 rows=1 loops=1)
- Index Scan using pk_tb_matricula on tb_matricula
(cost=0.00..4835.02 rows=351 width=0) (actual time=0.190..39.231 rows=1520
loops=1)
Index Cond: (((disccodof)::text = 'ADM082'::text) AND (ano =
2012))
Filter: ((localcod = 'C01'::bpchar) AND (((turmateo)::text =
'1'::text) OR ((turmapra)::text = ''::text)) AND ((regime = 'A'::bpchar) OR
((regime 'A'::bpchar) AND (periodo = 1
Total runtime: 39.591 ms
No aguardo!!
Em 8 de fevereiro de 2013 13:58, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Olá pessoal,
Temos uma tabela que em um determinado tempo ela é muito consultada e ao
mesmo tempo sofre muitos inserts e updates.
Acontece que a consulta é bem complexa e está ficando cada vez mais
lenta com
o aumento do número de dados.
Você poderia nos passar um EXPLAIN ANALYZE da consulta que está ficando
lenta?
Decidimos então testar a criação de uns índices com os principais campos
nas
cláusulas WHERE das consultas mais lentas.
A consulta ficou bem mais rápida, mas estamos receosos se estes índices
irão
deixar mais lenta a inserção e update de dados
pois esses comandos teriam então que inserir no índice também.
Sim, os INSERT e UPDATE vão ficar mais lentos.
Você terá de balancear o custo x benefício dos índices.
Pra saber se os índices estão sendo realmente eficientes para o SELECT,
envie-nos o EXPLAIN ANALYZE que solicitei acima.
Obs.:
Criamos 2 índices compostos btree.
(campo1, campo2, campo3)
(campo4, campo2, campo3)
campo2 e campo3 fazem parte da chave da tabela que possui 5 campos chave.
Detalhe: temos 2 consultas muito pesadas que usam no where campo1,
campo2 e
campo3 e campo4, campo2 e campo3 respectivamente.
Provavelmente o índice é interessante, mas só com o EXPLAIN ANALYZE dá pra
ajudar.
[]s
__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
*Wellington Openheimer Ribeiro*
Analista de Tecnologia da Informação
*UNIFEI - Universidade Federal de Itajubá*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Não repedir dados do campo...
Veja se pode lhe ajudar ( http://www.network-theory.co.uk/docs/postgresql/vol1/UniqueConstraints.html ) Nilson Chagas wrote: Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas no sei nem como procurar isto. Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, no testei mas at onde eu sei indices unicos no permitem duplicar campos nulos. Algum pode me esclarecer isto?? -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.avozdoevangelho.com.br - Pea gratuitamente um curso Bblico Twitter: avozdoevangelho Twitter: matrixspnet http://www.amados.com.br http://bbnradio.org - Oua a rdio e faa gratuitamente um Curso Biblico On-Line ___ 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
