[pgbr-geral] Ver a carga de processos em consultas no PG
Olá pessoal, Estava com ideia de saber o load (consumo de cpu) de cada consulta no servidor, eu pesquisei mas não encontrei nada pronto que pudesse ajudar, acabei fazendo um function em pl/phyton, que nada mais faz do que um "ps" pegando o procpid e verificando o uso da cpu, ficou assim: CREATE OR REPLACE FUNCTION public.pg_proc_load(procpid integer) RETURNS numeric LANGUAGE plpython2u AS $function$ import commands try: cmd1 = 'ps --no-header -o"%C" -p' + str(procpid) l = commands.getoutput(cmd1); except: l = 0.0 if len(l) == 0: l = 0.0 return float(l) $function$ o resultado é interessante, mas to achando o retorno muito lento, em média uns 600ms, acho que o uso ta bem legal pra quem precisa ou quer monitorar o load das consultas, por exemplo. select pg_proc_load(procpid), current_query from pg_stat_activite; Queria ver se alguém tem alguma sugestão para melhor a performance da function, pois meu conhecimento de python também é bem básico. Abraços, *Hugo Bastos Bucker** * ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Particionamento de tabelas row_count retona ZERO
Valeu Flavio, eu imaginei pelas pesquisas que fiz e testes... mas vc sabe, sempre é bom ter uma segunda opnião. Abraços, Hugo. Em 15 de dezembro de 2011 15:15, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > > Álguem já se deparou com o problema de ao particionar uma tabela o > ROW_COUNT > > retornar ZERO? > > Eu. > > > Será que tem como fazer a trigger retornar a quantidade de registros que > > foram inseridos, pois ao usar o "RETURN NULL" na trigger o PG não > > contabiliza a linha. > > Não, não tem como. > > > Como não tenho controle sobre a aplicação estou com receio de que ela > faça > > algum teste sobre a quantidade de registros incluídos. > > Sua aplicação não deveria fazer nenhum check aí, pois se o PostgreSQL > não retornar erros, quer dizer que o INSERT foi feito com sucesso, > exatamente como foi solicitado pela aplicação. > > Já passei por isso em aplicações Java com Hibernate. É possível > configurar o Hibernate pra não fazer essa verificação, que é > totalmente desprezível do ponto de vista do banco de dados. > > []s > Flavio Gurgel > ___ > 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] Particionamento de tabelas row_count retona ZERO
Boa Tarde a todos, Álguem já se deparou com o problema de ao particionar uma tabela o ROW_COUNT retornar ZERO? Será que tem como fazer a trigger retornar a quantidade de registros que foram inseridos, pois ao usar o "RETURN NULL" na trigger o PG não contabiliza a linha. Como não tenho controle sobre a aplicação estou com receio de que ela faça algum teste sobre a quantidade de registros incluídos. Abraços, *Hugo Bastos Bucker* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Reaproveitar retorno de Function em SELECT
Bom dia Renato, Em 8 de novembro de 2011 07:10, Renato Augusto escreveu: > Bom dia a todos, > > Estou com a seguinte situação nesse SQL: > > SELECT mod1.tb_oper_id AS operacao, > mod1.tb_modoper_tempo_bruto AS tempo_bruto, > mod1.tb_modoper_valorcusto AS valor_custo, > estabset1.tb_estset_eficcustos AS eficiencia, > ROUND((mod1.tb_modoper_tempo_bruto / > (estabset1.tb_estset_eficcustos / 100)),5) AS tempo_total, > ROUND((mod1.tb_modoper_valorcusto),5) AS valor_total, > tipooper1.tb_tipooper_tipo AS tipo_oper, > sch_custos.fun_custo_minuto_setor(mod1.sis_emp_id, > emp1.par_scu_tipo_calc_custo_minuto, pestab, oper1.tb_set_id, > tipooper1.tb_tipooper_tipo) AS custo_minuto, >FROM sch_pcp.tb_modoper mod1 > > Você pode tentar usar o WITH assim: WITH consulta AS ( SELECT mod1.tb_oper_id AS operacao, mod1.tb_modoper_tempo_bruto AS tempo_bruto, mod1.tb_modoper_valorcusto AS valor_custo, estabset1.tb_estset_eficcustos AS eficiencia, ROUND((mod1.tb_modoper_tempo_ > > bruto / > (estabset1.tb_estset_eficcustos / 100)),5) AS tempo_total, > ROUND((mod1.tb_modoper_valorcusto),5) AS valor_total, > tipooper1.tb_tipooper_tipo AS tipo_oper, > sch_custos.fun_custo_minuto_setor(mod1.sis_emp_id, > emp1.par_scu_tipo_calc_custo_minuto, pestab, oper1.tb_set_id, > tipooper1.tb_tipooper_tipo) AS custo_minuto, >FROM sch_pcp.tb_modoper mod1 > ) SELECT * FROM consulta WHERE tempo_total > 10; > O que acontece é que tenho que chamar mais uma Function -> > sch_pcp.fun_valor_impostos_operacao() onde um de seus parâmetros é o > resultado da expressão do primeiro ROUND e outro parâmetro é o > resultado da Function sch_custos.fun_custo_minuto_setor() chamada > também no SQL.. > O resultado desta Function de valor de impostos deve ser aproveitado > no cálculo para encontrar o Valor Líquido Final. > > > A questão é: > - Como o Alias do Round nem da Function é reconhecido dentro da > sentença, é possível armazenar um valor calculado em uma expressão ou > o valor do Result de uma Function para ser aproveitado na mesma > sentença sem fazer novamente a chamada desta Function ? > > Obrigado. > > Renato Becker. > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > Abraços. Hugo B. Bucker ___ 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] Pós Graduação com ênfase em PostgreSQL
*Pós Graduação em Administração de Banco de Dados com ênfase em PostgreSQL.
*
*Boa tarde,
Gostaria de divulgar nosso curso de Pós graduação que está sendo lançado
pela UCDB/MS, lembrando que todos os módulos são direcionados a utilização
do PG.
As inscrições estão aberta.
Informações e dúvidas podem ser tiradas diretamente comigo ou pelo site *
*http://www.ucdb.br/pos*
*
Estrutura do Curso:*
*Carga Horária Total: 420 horas/aula*
* 1. SQL (DDL e DML) 48h/a
*
Apresentar os conceitos intermediário e avançados sobre o conjunto de
comandos SQL.
* 2. Engenharia de Requisitos 24h/a*
Apresentar técnicas de levantamento e documentação de requisitos.
* 3. Modelagem de Banco de Dados 24h/a
*
Conceitos de Normalização, Entidades, Atributos, Relacionamentos,
Chaves primárias e estrangeiras, restrição de integridade (chave,
entidade e referencial), elaboração de Diagramas e Dicionarios de Dados
* 4. Programação Procedural 48h/a*
Estender os conceitos e aplicação da programação procedural, usando
a linguagem pl/pgsql
* 5. Administração S.O. Linux 24h/a*
Entender e praticar a Instalação do Linux e conhecer os conceitos
básicos do S.O., sistemas de arquivos, RAID de Software e Hardware
* 6. Administração de Banco de Dados 48h/a*
Entender e praticar a Instalação e configuração do PostgreSQL
* 7. Otimização de Banco de Dados 24h/a
*
Familiarizar o aluno com conceitos de tuning e otimização em banco de
dados
* 8. Auditoria e Segurança 36h/a*
Habilitar o aluno à identificar falhas de segurança e criar
estratégias de segurança e auditoria.
* 9. Bancos de Dados Não Convencionais 36h/a
*
Capacitar o aluno na utilização dos recursos Objeto-Relacionais,
presentes no PostgreSQL.
*10. Integração de Dados 36h/a*
Apresentar ao acadêmico técnicas de importação de arquivos em lote,
assim como exportação de arquivos em formatos txt, csv e xml.
*11. Bancos de Dados Distribuídos 36h/a
*
Capacitar ao aluno em desenvolver um projeto de banco de dados
distribuídos, instalar e configurar ferramentas no PostgreSQL.
*12. Data Warehouse e Tecnologias OLAP 24h/a*
Apresentar o conceito de Sistema de Informações e Sistemas de Suporte
à Decisão. Apresentar o conceito de Data Warehouse para a construção
de Sistemas de Suporte à Decisão e as principais ferramentas para
o processo de tomada de decisões: OLAP (On-Line Analytical Processing)
e Mineração de Dados (Data Mining).
*13. Métodos e Técnicas de Pesquisa 24h/a*
*14. Metodologia do Ensino Superior 24h/a
*
Abraços,
*Hugo Bastos Bucker*
*Universidade Católica Dom Bosco/MS*
\- Professor
*Tendência Integrando Tecnologias*
\- Administrador de Banco de Dados
*Campo Grande/Mato Grosso do Sul*
Esp. Desenvolvimento de Aplicações para WWW
Esp. Administração de Banco de Dados
hbbucker@{gmail.com; yahoo.com.br}
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Collation
Olá, Em 22 de setembro de 2011 09:59, Euler Taveira de Oliveira < eu...@timbira.com> escreveu: > On 21-09-2011 14:59, Danilo Silva wrote: > > Instalei a versão 9.1 em ambiente windows xp. > > Como a nova versão trata o collation? > Collation pode ser especificada por coluna e tabela a partir da 9.1. Em > versões anteriores ela tinha que ser definida para todo o agrupamento de > banco > de dados. > > > É possível criar novos collations? Como? > Sim. Vide CREATE COLLATION [1]. Tenha em mente que o seu sistema > operacional > deve ter essa configuração regional instalada. > > > > Essas perguntas fazem necessário devido ao problema de consultas em campo > que > > possuem acentuação, exemplo: se tenho guardado as strings 'AÇÃO', > 'CONSTRUÇÃO' > > e 'CAOS', se efetuar uma select: SELECT campo FROM tabela WHERE campo > ILIKE > > '%cao%' => só irá retornar a string 'caos', mas preciso que retorne tudo > (com > > e sem acento). Em mysql não tem esse problema a versão na qual testei usa > > collation latin1_swedish_ci. > > > A implementação de collation do PostgreSQL ainda *não* tem suporte para > comparar cadeias de caracteres sem observar se estão: (i) em maiúsculas ou > minúsculas e (ii) com acento e sem acento. Você terá que utilizar > operadores e > funções que te auxiliem na normalização das cadeias de caracteres para > comparação das mesmas (vide por exemplo ILIKE [2], expressões regulares [2] > e > unaccent [3]). > Se vc tem um banco LATIN1, LATIN2, LATIN9, ou WIN1250 você poderia usar a função to_ascii()[1] para remover os acentos. > [1] http://www.postgresql.org/docs/current/static/sql-createcollation.html > [2] http://www.postgresql.org/docs/current/static/functions-matching.html > [3] http://www.postgresql.org/docs/current/static/unaccent.html > > > -- >Euler Taveira de Oliveira - 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 > [1] http://www.postgresql.org/docs/9.0/static/functions-string.html Hugo B. Bucker ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Distribuição de Carga de Dados.
Em 15 de setembro de 2011 17:05, Guimarães Faria Corcete DUTRA, Leandro < lean...@dutras.org> escreveu: > 2011/9/15 Hugo Bastos Bucker : > > > > acredito que vc está querendo é fazer um particionamento de tabelas [1], > mas > > não é uma solução muito convencional. > > O que há de não convencional em particionamento de tabelas? > > > Bom... pelo menos eu não tenho visto muitas tabelas particionadas rodando > -- > Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org > +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm > sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > []'s Hugo B. Bucker ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Distribuição de Carga de Dados.
Olá Luciano Em 15 de setembro de 2011 09:52, Luciano Schardosim escreveu: > Pessoal, > > Vamos imaginar o seguinte cenário: tenho uma instancia de postgres e dentro > dessa instância tenho um schema chamado base_principal. Depois de muito > insert, o volume da base esta ocupando quase todo meu storage (não importa > qual o tipo de storage). O que importa é que agora eu quero poder alocar uma > nova área de armazenamento e quero que os dados da minha instancia sejam > distribuidos entre esse dois ambientes de armazenamento automaticamente, ou > seja, a cada nova área de armazenamento que eu adicionar, o postgres faz a > distribuição dos dados entre eles. Essa distribuição eu quero que seja > controlada pelo SGBD e não pelo sistema operacional. > > Se tiverem alguma dica, pois pelo que entendi a tablespace do Postgres não > trabalha com o conceito de container e preciso de uma solução similar, seja > por tablespace, seja por múltiplas instancias Enfim... > > Mais uma vez, valeu gurizada!!! :D > > Está é minha primeira participação espero poder contribuir de alguma forma, acredito que vc está querendo é fazer um particionamento de tabelas [1], mas não é uma solução muito convencional. [1] http://www.postgresql.org/docs/current/static/ddl-partitioning.html > Luciano Schardosim > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > []'s Hugo B. Bucker ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
