Re: [pgbr-geral] Como analisar a causa out of memory?
Em 9 de julho de 2013 19:03, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 17:55, Luiz Carlos L. Nogueira Jr. wrote: Pessoal, Apesar de eu não ter acreditado, parece que resolveu mudei o overcommit_ratio de 50 pra 100 e 6 horas sem out of memory Eu não recomendaria utilizar 100 (apesar que alguns artigos recomendarem). Eu deixaria alguma memória para ser utilizada pelo SO e alguma outra aplicação acessório. Por isso, eu recomendaria *não* utilizar 100 mas um valor próximo. É polêmico mesmo... eu costumo usar 80%. No caso aqui, como o swap é muito pequeno, o risco é maior. Aumentando o swap a conta fica melhor. -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://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
Re: [pgbr-geral] Dívida shared_buffers
Linux Em 10 de julho de 2013 08:49, Matheus de Oliveira matioli.math...@gmail.com escreveu: 2013/7/9 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com Pessoal, Tenho uma máquina de 32GB com shared_buffers=6GB Quando reinicio a mesma não vejo esses 6GB serem alocados na memória. O PostgreSQL aloca essa memória, mas não necessariamente o SO vai disponibilizá-la de imediato, podendo deixar como memória virtual. Onde poderia ver isso no SO? Qual SO? 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] [OFF] Kernel tuning para cargas extremas de I/O de disco e rede para SGBD e e-mail
Descrição: Cargas de escritas síncronas aleatórias extremas de I/O de rede e discos, para arquivos pequenos e curtas requisições de rede em ambientes corporativos estão presentes em servidores de e-mail e banco de dados. Apresentaremos lições aprendidas de Debian GNU/Linux kernel tuning já implantadas em produção em escala governamental, sobre hardware e data storage servers classe high-end. Ambientes corporativos em escala governamental ou enterprise utilizam servidores, rede, data storage servers conectados por fibra ótica que se comportam diferentemente de servidores menores e ainda mais quando submetidos a cargas extremas de I/O por servidores de e-mail e bancos de dados. Tais serviços demandam escritas aleatórias síncronas de arquivos pequenos em grande volume e simultâneas, o pior cenário para toda cadeia de hardware e software. Numa proporção escrita/leitura que pode chegar 95%. O que nunca é descrito em benchmarks publicados nem em revistas e muito menos por empresas. Apresentaremos dicas de escolha de hardware que não estão em folhetos nem conversa de vendedor, e técnicas de análise, tuning e benchmark próprios para tal cenário. Tais tunings já estão implantados em ambiente de produção sob cargas de escala governamental há mais de 1 ano com excelentes resultados. Palestrante: André Felipe Machado Minicurrículo: Colaborador do Projeto Debian, participa do Time de Parceiros, do Time de Publicidade e do Grupo de Usuários Debian-RS e Debian Brasil. Usa Linux desde 1998 e computadores desde o cartão perfurado. Engenheiro em Eletrônica desde 1988, programou de micro-kernel Real Time em microcontroladores fazendo DSP em C e Assembly até sistemas web. Implantou, administrou e otimizou redes e servidores de arquivos, e-mail, aplicação, banco de dados. Blog pessoal www.techforce.com.br. Desde 2005 trabalha no SERPRO. Transmissão: A atividade será transmitida via internet pelo serviço Assiste - Vídeo Streaming Livre do Serpro. Para acompanhar, acesse: assiste.serpro.gov.br/cisl/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] FuzzyStrMatch - um bom índice para levenshtein
Caros,
Estou trabalhando em um sistema cuja comparação de similaridade de nomes
dos detentos é extremamente importante a fim de detectar possíveis
fugitivos.
Por conta disso, usarei a extensão FuzzyStrMatch, com as 5 funções
disponíveis, para disparar alertas aos policiais para verificarem e
compararem as fichas de quem está sendo detido e quem é fugitivo.
Até o momento, tudo quase ok (tirando o fato de que não é para idiomas
latinos, mas já é algo). Só que fiquei com dúvida sobre qual seria um bom
valor para o índice Levenshtein. Estou extremamente compelido pelo índice
3, mas gostaria de opiniões.
Eis um exemplo de teste que mostrou-se satisfatório
select soundex('Josefa Silva'), soundex('Joseph Silva');
select levenshtein('Josefa Silva', 'Joseph Silva');
select metaphone('Josefa Silva', 10), metaphone('Joseph Silva', 10);
select dmetaphone('Josefa Silva'), dmetaphone('Joseph Silva');
select dmetaphone_alt('Josefa Silva'), dmetaphone_alt('Joseph Silva');
Neste caso, todos retornam iguais, mas quando mudamos de Josefa para José
(que é muito parecido com Joseph, inclusive no que tange ao gênero do
substantivo) só Levenshtein na causa para salvar, hehehe. O resultado vira
3. No caso de mudarmos para João vs Joseph, índice 4, e João vs José,
índice 2.
Enfim... opiniões?
--
*
Pablo Santiago Sánchez*
ZCE ZEND006757
phack...@gmail.com
(61) 9975-0883
http://www.sansis.com.br
*Pluralitas non est ponenda sine necessitate*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] Kernel tuning para cargas extremas de I/O de disco e rede para SGBD e e-mail
Em 10 de julho de 2013 10:24, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: 2013/7/10 Juliano Atanazio juliano.l...@gmail.com Descrição: Cargas de escritas síncronas aleatórias extremas de I/O de rede e discos, para arquivos pequenos e curtas requisições de rede em ambientes corporativos estão presentes em servidores de e-mail e banco de dados. Apresentaremos lições aprendidas de Debian GNU/Linux kernel tuning já implantadas em produção em escala governamental, sobre hardware e data storage servers classe high-end. Ambientes corporativos em escala governamental ou enterprise utilizam servidores, rede, data storage servers conectados por fibra ótica que se comportam diferentemente de servidores menores e ainda mais quando submetidos a cargas extremas de I/O por servidores de e-mail e bancos de dados. Tais serviços demandam escritas aleatórias síncronas de arquivos pequenos em grande volume e simultâneas, o pior cenário para toda cadeia de hardware e software. Numa proporção escrita/leitura que pode chegar 95%. O que nunca é descrito em benchmarks publicados nem em revistas e muito menos por empresas. Apresentaremos dicas de escolha de hardware que não estão em folhetos nem conversa de vendedor, e técnicas de análise, tuning e benchmark próprios para tal cenário. Tais tunings já estão implantados em ambiente de produção sob cargas de escala governamental há mais de 1 ano com excelentes resultados. Palestrante: André Felipe Machado Minicurrículo: Colaborador do Projeto Debian, participa do Time de Parceiros, do Time de Publicidade e do Grupo de Usuários Debian-RS e Debian Brasil. Usa Linux desde 1998 e computadores desde o cartão perfurado. Engenheiro em Eletrônica desde 1988, programou de micro-kernel Real Time em microcontroladores fazendo DSP em C e Assembly até sistemas web. Implantou, administrou e otimizou redes e servidores de arquivos, e-mail, aplicação, banco de dados. Blog pessoal www.techforce.com.br. Desde 2005 trabalha no SERPRO. Transmissão: A atividade será transmitida via internet pelo serviço Assiste - Vídeo Streaming Livre do Serpro. Para acompanhar, acesse: assiste.serpro.gov.br/cisl/ Juliando, quando (data e hora) ? Desculpe, Fabrízio. Era justamente isso que estava tentando consertar aqui rs. Quando: 16/07/2013 de 10:00 até 12:00 Onde: Auditório do Serpro regional - Porto Alegre Vale reforçar que quem não puder ir pessoalmente pode ver via streaming no horário marcado ou até mesmo posteriormente em: assiste.serpro.gov.br/cisl/ []s Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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] FuzzyStrMatch - um bom índice para levenshtein
On 10-07-2013 10:23, Pablo Sánchez wrote:
Até o momento, tudo quase ok (tirando o fato de que não é para idiomas
latinos, mas já é algo). Só que fiquei com dúvida sobre qual seria um
bom valor para o índice Levenshtein. Estou extremamente compelido pelo
índice 3, mas gostaria de opiniões.
Não existe índice bom ou ruim; tudo depende de (i) seus dados e (ii) o
quão flexível você quer ser. Faça bastante testes em uma baseline e
decida qual é o ideal.
Eis um exemplo de teste que mostrou-se satisfatório
select soundex('Josefa Silva'), soundex('Joseph Silva');
select levenshtein('Josefa Silva', 'Joseph Silva');
select metaphone('Josefa Silva', 10), metaphone('Joseph Silva', 10);
select dmetaphone('Josefa Silva'), dmetaphone('Joseph Silva');
select dmetaphone_alt('Josefa Silva'), dmetaphone_alt('Joseph Silva');
Eu não aconselharia utilizar qualquer dessas funções em nomes completos.
O soundex, por exemplo, considera somente algumas posições (no mínimo 4
caracteres). O levenshtein utilizado com strings longas podem ter mais
do que 3 ou 4 mudanças. Ao invés disso, quebre o nome completo em nome e
sobrenome e faça uma comparação individual ou utilize uma composição de
funções de similaridade.
Se você quer usar funções por similaridade, eu aconselho dar uma olhada
no pg_similarity [1]. Ele contém uma série de funções que podem te
auxiliar na tarefa de casamento flexível de strings.
[1] https://github.com/eulerto/pg_similarity
--
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] fazendo where em campo do tipo xml
As boas regras de educação numa lista de discussão pedem que não se faça
top-post (responder acima de tudo). Então, pedimos a gentileza de quotar
seus e-mails ao responder.
Em 10-07-2013 11:36, jorge sanfelice escreveu:
Alguem mais pode ajudar?
Outras boas regras de educação pedem que não se fique cobrando
respostas, pois as pessoas são voluntárias e usam parte de seu tempo
livre para ajudar. Então, pedimos não fazer mais isso.
Referente ao manual na parte 8.13.3. Accessing XML Values, nao
encontrei nada especifico.
Precisava saber como seria o modo correto de fazer Where nesse tipo
de coluna, ou até mesmo saber se isso é possivel.
select * from tabela where coluna_xml 'AWX555';
Seria algo assim, nao sei qual o correto usar, =, like, ilike , in
etc
Veja a documentação em:
http://www.postgresql.org/docs/9.2/static/xml2.html
Verifique se xpath_table resolve seu problema. É uma função que permite
transformar xml em uma espécie de tabela virtual onde você pode fazer
filtros com WHERE e até junções com JOIN.
Você terá de fazer algo como:
SELECT xpath_table ('coluna_chave', 'coluna_desejada', 'tabela',
'expressões', 'critério') AS foo WHERE foo.coluna_desejada = 'filtro
desejado';
Teste.
[]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
Re: [pgbr-geral] FuzzyStrMatch - um bom índice para levenshtein
Alguém tem idéia de como eu faço para mandar essa contribuição para o
pessoal do Postgres para que tenhamos lá um suporte para soundex para
latin? E alguém tem idéias para acrescentar, já que eu só fiz um pouco
de nada que já me resolve horrores aqui, mas que com certeza não é nem
10% do total para fechar com chave de ouro esse código?
Em 10 de julho de 2013 14:45, Pablo Sánchez phack...@gmail.com escreveu:
Já resolvi aqui a questão.
Segue o que eu implementei com base em um código que encontrei na Net
(mas fechei a aba e estava em modo anônimo, perdi qual era - créditos
para outra pessoa).
Coloquei o peso do Ç igual ao peso de C que é igual ao peso de S e de
X e coloquei o ÃO e ÕE com o peso de M caso o cara tenha escrito um
JOAUM ao invés de JOÃO.
Só respondendo: não quero ser muito flexível, por isso eliminei uma
penca de coisas e deixei o índice apenas como = 1. E sim, o cadastro
de detentos é sempre feito com o nome completo. Só para te dar uma
base de como ficou bacana, o teste foi assim:
SELECT LATINEX('Joaum Culioins da Çilva Roxa'), LATINEX('João Culhões
da Silva Rocha');
Veja que a assinatura de ambos é idêntica.
Meu problema está apenas com o raio da letra W que pode ter som de V
ou se U como em Wallace e Watson. Nesse caso a assinatura de todo o
restante é idêntica, exceto a primeira letra. Não posso descartar, mas
posso colocar uma margem de 1 se eu simplesmente pegar os resultados
como parte de levenschtein e manter o índice em = 1. Acredito que
isso me ajude também a pegar similaridades como Jasmin e Yasmin.
Assim, eis o que eu tenho:
-- Resultado levenshtein = 0, porque o primeiro caractere é idêntico
SELECT LEVENSHTEIN(LATINEX('Joaum Culioins da Çilva Roxa'),
LATINEX('João Culhões da Silva Rocha'))
-- Resultados levenshtein = 1, porque o primeiro caractere é o único que
SELECT LEVENSHTEIN(LATINEX('Uólaci Culioins da Çilva Roxa'),
LATINEX('Wallace Culhões da Silva Rocha'))
SELECT LEVENSHTEIN(LATINEX('Wanezza Culioins da Çilva Roxa'),
LATINEX('Vanessa Culhões da Silva Rocha'))
SELECT LEVENSHTEIN(LATINEX('Amiltão Culioins da Çilva Roxa'),
LATINEX('Hamilton Culhões da Silva Rocha'))
--Criação da função de peso do som das consoantes para cálculo de soundex
latin
CREATE OR REPLACE FUNCTION pesom(CHARACTER)
RETURNS INTEGER AS
$BODY$
SELECT
CASE $1
WHEN 'B' THEN 1
WHEN 'C' THEN 2
WHEN 'D' THEN 3
WHEN 'F' THEN 1
WHEN 'G' THEN 2
WHEN 'J' THEN 2
WHEN 'K' THEN 2
WHEN 'L' THEN 4
WHEN 'M' THEN 5
WHEN 'N' THEN 5
WHEN 'P' THEN 1
WHEN 'Q' THEN 2
WHEN 'R' THEN 6
WHEN 'S' THEN 2
WHEN 'T' THEN 3
WHEN 'V' THEN 1
WHEN 'X' THEN 2
WHEN 'Z' THEN 2
ELSE 0
END
$BODY$
LANGUAGE 'sql' VOLATILE
COST 100;
ALTER FUNCTION pesom(CHARACTER) OWNER TO postgres;
--Criação da função de peso do som das consoantes para cálculo de soundex
latin
CREATE OR REPLACE FUNCTION latinex(CHARACTER VARYING)
RETURNS CHARACTER AS
$BODY$
DECLARE
texto VARCHAR;
resultado VARCHAR;
i INT;
ipesom INT;
valorPrimeiraLetra INT;
BEGIN
texto = $1;
texto = UPPER(texto);
texto = TRANSLATE(texto, 'ãO', 'M');
texto = TRANSLATE(texto, 'ÃO', 'M');
texto = TRANSLATE(texto, 'õE', 'M');
texto = TRANSLATE(texto, 'ÕE', 'M');
texto = TRANSLATE(texto, 'ñ', 'N');
texto = TRANSLATE(texto, 'Ñ', 'N');
texto = TRANSLATE(texto, 'ç', 'C');
texto = TRANSLATE(texto, 'Ç', 'C');
resultado = SUBSTRING(texto,1,1);
valorPrimeiraLetra = pesom(resultado);
i=2;
WHILE i LENGTH(texto) LOOP
ipesom = pesom(SUBSTRING(texto, i, 1));
IF (NOT (ipesom = 0) AND NOT (valorPrimeiraLetra = ipesom)) THEN
resultado = resultado || ipesom;
END IF;
valorPrimeiraLetra = ipesom;
ipesom = 0;
i := i + 1;
END LOOP;
WHILE LENGTH(resultado) 4 LOOP
resultado = resultado || '0';
END LOOP;
RETURN resultado;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION latinex(CHARACTER VARYING) OWNER TO postgres;
Em 10 de julho de 2013 11:13, Euler Taveira eu...@timbira.com.br escreveu:
On 10-07-2013 10:23, Pablo Sánchez wrote:
Até o momento, tudo quase ok (tirando o fato de que não é para idiomas
latinos, mas já é algo). Só que fiquei com dúvida sobre qual seria um
bom valor para o índice Levenshtein. Estou extremamente compelido pelo
índice 3, mas gostaria de opiniões.
Não existe índice bom ou ruim; tudo depende de (i) seus dados e (ii) o
quão flexível você quer ser. Faça bastante testes em uma baseline e
decida qual é o ideal.
Eis um exemplo de teste que mostrou-se satisfatório
select soundex('Josefa Silva'), soundex('Joseph Silva');
select levenshtein('Josefa Silva', 'Joseph Silva');
select metaphone('Josefa Silva', 10), metaphone('Joseph Silva', 10);
select dmetaphone('Josefa Silva'), dmetaphone('Joseph Silva');
select dmetaphone_alt('Josefa Silva'), dmetaphone_alt('Joseph Silva');
Eu não aconselharia utilizar qualquer
Re: [pgbr-geral] FuzzyStrMatch - um bom índice para levenshtein
Achei a página original do código. Dá para ver que eu não fiz muita
coisa além de colocar uns translates bestas.
http://www.mloyola.com.br/site/busca-fonetica-postgresql
Menção honrosa para o Marcus Loyola que foi quem disponibilizou o
código original.
Em 10 de julho de 2013 14:50, Pablo Sánchez phack...@gmail.com escreveu:
Alguém tem idéia de como eu faço para mandar essa contribuição para o
pessoal do Postgres para que tenhamos lá um suporte para soundex para
latin? E alguém tem idéias para acrescentar, já que eu só fiz um pouco
de nada que já me resolve horrores aqui, mas que com certeza não é nem
10% do total para fechar com chave de ouro esse código?
Em 10 de julho de 2013 14:45, Pablo Sánchez phack...@gmail.com escreveu:
Já resolvi aqui a questão.
Segue o que eu implementei com base em um código que encontrei na Net
(mas fechei a aba e estava em modo anônimo, perdi qual era - créditos
para outra pessoa).
Coloquei o peso do Ç igual ao peso de C que é igual ao peso de S e de
X e coloquei o ÃO e ÕE com o peso de M caso o cara tenha escrito um
JOAUM ao invés de JOÃO.
Só respondendo: não quero ser muito flexível, por isso eliminei uma
penca de coisas e deixei o índice apenas como = 1. E sim, o cadastro
de detentos é sempre feito com o nome completo. Só para te dar uma
base de como ficou bacana, o teste foi assim:
SELECT LATINEX('Joaum Culioins da Çilva Roxa'), LATINEX('João Culhões
da Silva Rocha');
Veja que a assinatura de ambos é idêntica.
Meu problema está apenas com o raio da letra W que pode ter som de V
ou se U como em Wallace e Watson. Nesse caso a assinatura de todo o
restante é idêntica, exceto a primeira letra. Não posso descartar, mas
posso colocar uma margem de 1 se eu simplesmente pegar os resultados
como parte de levenschtein e manter o índice em = 1. Acredito que
isso me ajude também a pegar similaridades como Jasmin e Yasmin.
Assim, eis o que eu tenho:
-- Resultado levenshtein = 0, porque o primeiro caractere é idêntico
SELECT LEVENSHTEIN(LATINEX('Joaum Culioins da Çilva Roxa'),
LATINEX('João Culhões da Silva Rocha'))
-- Resultados levenshtein = 1, porque o primeiro caractere é o único que
SELECT LEVENSHTEIN(LATINEX('Uólaci Culioins da Çilva Roxa'),
LATINEX('Wallace Culhões da Silva Rocha'))
SELECT LEVENSHTEIN(LATINEX('Wanezza Culioins da Çilva Roxa'),
LATINEX('Vanessa Culhões da Silva Rocha'))
SELECT LEVENSHTEIN(LATINEX('Amiltão Culioins da Çilva Roxa'),
LATINEX('Hamilton Culhões da Silva Rocha'))
--Criação da função de peso do som das consoantes para cálculo de soundex
latin
CREATE OR REPLACE FUNCTION pesom(CHARACTER)
RETURNS INTEGER AS
$BODY$
SELECT
CASE $1
WHEN 'B' THEN 1
WHEN 'C' THEN 2
WHEN 'D' THEN 3
WHEN 'F' THEN 1
WHEN 'G' THEN 2
WHEN 'J' THEN 2
WHEN 'K' THEN 2
WHEN 'L' THEN 4
WHEN 'M' THEN 5
WHEN 'N' THEN 5
WHEN 'P' THEN 1
WHEN 'Q' THEN 2
WHEN 'R' THEN 6
WHEN 'S' THEN 2
WHEN 'T' THEN 3
WHEN 'V' THEN 1
WHEN 'X' THEN 2
WHEN 'Z' THEN 2
ELSE 0
END
$BODY$
LANGUAGE 'sql' VOLATILE
COST 100;
ALTER FUNCTION pesom(CHARACTER) OWNER TO postgres;
--Criação da função de peso do som das consoantes para cálculo de soundex
latin
CREATE OR REPLACE FUNCTION latinex(CHARACTER VARYING)
RETURNS CHARACTER AS
$BODY$
DECLARE
texto VARCHAR;
resultado VARCHAR;
i INT;
ipesom INT;
valorPrimeiraLetra INT;
BEGIN
texto = $1;
texto = UPPER(texto);
texto = TRANSLATE(texto, 'ãO', 'M');
texto = TRANSLATE(texto, 'ÃO', 'M');
texto = TRANSLATE(texto, 'õE', 'M');
texto = TRANSLATE(texto, 'ÕE', 'M');
texto = TRANSLATE(texto, 'ñ', 'N');
texto = TRANSLATE(texto, 'Ñ', 'N');
texto = TRANSLATE(texto, 'ç', 'C');
texto = TRANSLATE(texto, 'Ç', 'C');
resultado = SUBSTRING(texto,1,1);
valorPrimeiraLetra = pesom(resultado);
i=2;
WHILE i LENGTH(texto) LOOP
ipesom = pesom(SUBSTRING(texto, i, 1));
IF (NOT (ipesom = 0) AND NOT (valorPrimeiraLetra = ipesom)) THEN
resultado = resultado || ipesom;
END IF;
valorPrimeiraLetra = ipesom;
ipesom = 0;
i := i + 1;
END LOOP;
WHILE LENGTH(resultado) 4 LOOP
resultado = resultado || '0';
END LOOP;
RETURN resultado;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
ALTER FUNCTION latinex(CHARACTER VARYING) OWNER TO postgres;
Em 10 de julho de 2013 11:13, Euler Taveira eu...@timbira.com.br escreveu:
On 10-07-2013 10:23, Pablo Sánchez wrote:
Até o momento, tudo quase ok (tirando o fato de que não é para idiomas
latinos, mas já é algo). Só que fiquei com dúvida sobre qual seria um
bom valor para o índice Levenshtein. Estou extremamente compelido pelo
índice 3, mas gostaria de opiniões.
Não existe índice bom ou ruim; tudo depende de (i) seus dados e (ii) o
quão flexível você quer ser. Faça bastante testes em uma baseline e
decida qual é o ideal.
Eis um exemplo de teste que mostrou-se satisfatório
select
Re: [pgbr-geral] FuzzyStrMatch - um bom índice para levenshtein
Meus caros,
Devido a um pequeno desafio (Valdisnei vs Walt Disney), mantendo o uso
de Levenschtein com índice de erro 1 apenas para palavras iniciadas em
W, U e V, precisei reescrever a função para ignorar os espaços em
branco, pois o T passava a ter peso por vir ao final de uma palavra,
gerando um resultado distinto.
Eis o que sobrou:
TESTES:
SELECT LEVENSHTEIN(LATINEX('Joaum Culioins da Çilva Roxa'),
LATINEX('João Culhões da Silva Rocha'));
SELECT LEVENSHTEIN(LATINEX('Valdisnei'), LATINEX('Walt Disney'));
SELECT LEVENSHTEIN(LATINEX('Uólaci Martinez de Çouza Broxado'),
LATINEX('Wallace Martins de Sousa Brochado'));
SELECT LEVENSHTEIN(LATINEX('Wanezza Manguabeira da Costta'),
LATINEX('Vanessa Mangabeira da Costa'));
SELECT LEVENSHTEIN(LATINEX('Amiltão De Georgio'), LATINEX('Hamilton Di
Giorgio'));
SELECT LATINEX('Joaum Culioins da Çilva Roxa'), LATINEX('João Culhões
da Silva Rocha');
SELECT LATINEX('Valdisnei'), LATINEX('Walt Disney');
SELECT LATINEX('Uólaci Martinez de Çouza Broxado'), LATINEX('Wallace
Martins de Sousa Brochado');
SELECT LATINEX('Wanezza Manguabeira da Costta'), LATINEX('Vanessa
Mangabeira da Costa');
SELECT LATINEX('Amiltão De Georgio'), LATINEX('Hamilton Di Giorgio');
-- Criação da função de peso do som das consoantes para cálculo de soundex latin
-- Function: latinex(character varying)
-- DROP FUNCTION latinex(character varying);
CREATE OR REPLACE FUNCTION latinex(character varying)
RETURNS character AS
$BODY$
DECLARE
texto VARCHAR;
resultado VARCHAR;
i INT;
ipesom INT;
valorPrimeiraLetra INT;
c VARCHAR;
BEGIN
texto = $1;
texto = UPPER(texto);
texto = TRANSLATE(texto, 'ãO', 'M');
texto = TRANSLATE(texto, 'ÃO', 'M');
texto = TRANSLATE(texto, 'õE', 'M');
texto = TRANSLATE(texto, 'ÕE', 'M');
texto = TRANSLATE(texto, 'ç', 'C');
texto = TRANSLATE(texto, 'Ç', 'C');
texto = TRANSLATE(texto, 'ñ', 'N');
texto = TRANSLATE(texto, 'Ñ', 'N');
resultado = SUBSTRING(texto,1,1);
valorPrimeiraLetra = pesom(resultado);
i=2;
WHILE i LENGTH(texto) LOOP
c = SUBSTRING(texto, i, 1);
ipesom = pesom(c);
IF (
NOT (ipesom = 0) AND
NOT (valorPrimeiraLetra = ipesom)
) THEN
resultado = resultado || ipesom;
END IF;
IF (
NOT (c = ' ') AND
NOT (c = ) AND
NOT (c = '-') AND
NOT (c = 'A') AND
NOT (c = 'E') AND
NOT (c = 'I') AND
NOT (c = 'O') AND
NOT (c = 'U')
) THEN
valorPrimeiraLetra = ipesom;
ipesom = 0;
END IF;
i := i + 1;
END LOOP;
WHILE LENGTH(resultado) 4 LOOP
resultado = resultado || '0';
END LOOP;
RETURN resultado;
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION latinex(character varying)
OWNER TO postgres;
Em 10 de julho de 2013 15:01, Pablo Sánchez phack...@gmail.com escreveu:
Achei a página original do código. Dá para ver que eu não fiz muita
coisa além de colocar uns translates bestas.
http://www.mloyola.com.br/site/busca-fonetica-postgresql
Menção honrosa para o Marcus Loyola que foi quem disponibilizou o
código original.
Em 10 de julho de 2013 14:50, Pablo Sánchez phack...@gmail.com escreveu:
Alguém tem idéia de como eu faço para mandar essa contribuição para o
pessoal do Postgres para que tenhamos lá um suporte para soundex para
latin? E alguém tem idéias para acrescentar, já que eu só fiz um pouco
de nada que já me resolve horrores aqui, mas que com certeza não é nem
10% do total para fechar com chave de ouro esse código?
Em 10 de julho de 2013 14:45, Pablo Sánchez phack...@gmail.com escreveu:
Já resolvi aqui a questão.
Segue o que eu implementei com base em um código que encontrei na Net
(mas fechei a aba e estava em modo anônimo, perdi qual era - créditos
para outra pessoa).
Coloquei o peso do Ç igual ao peso de C que é igual ao peso de S e de
X e coloquei o ÃO e ÕE com o peso de M caso o cara tenha escrito um
JOAUM ao invés de JOÃO.
Só respondendo: não quero ser muito flexível, por isso eliminei uma
penca de coisas e deixei o índice apenas como = 1. E sim, o cadastro
de detentos é sempre feito com o nome completo. Só para te dar uma
base de como ficou bacana, o teste foi assim:
SELECT LATINEX('Joaum Culioins da Çilva Roxa'), LATINEX('João Culhões
da Silva Rocha');
Veja que a assinatura de ambos é idêntica.
Meu problema está apenas com o raio da letra W que pode ter som de V
ou se U como em Wallace e Watson. Nesse caso a assinatura de todo o
restante é idêntica, exceto a primeira letra. Não posso descartar, mas
posso colocar uma margem de 1 se eu simplesmente pegar os resultados
como parte de levenschtein e manter o índice em = 1. Acredito que
isso me ajude também a pegar similaridades como Jasmin e Yasmin.
Assim, eis o que eu tenho:
-- Resultado levenshtein = 0, porque o primeiro caractere é idêntico
SELECT LEVENSHTEIN(LATINEX('Joaum Culioins da Çilva Roxa'),
LATINEX('João Culhões da Silva Rocha'))
-- Resultados levenshtein = 1, porque o primeiro caractere é o único que
SELECT LEVENSHTEIN(LATINEX('Uólaci Culioins da Çilva Roxa'),
LATINEX('Wallace Culhões da Silva Rocha'))
SELECT
[pgbr-geral] indices densos esparsos
Pessoal, o postgre ele tem suporte para indices densos e esparsos? Att,Lucas José Duarte de SouzaBacharelando em Ciência da ComputaçãoUniversidade Federal de Lavras.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] indices densos esparsos
Sim possuí e são indices apontadores. Em 10 de julho de 2013 20:07, lucas . lucasouz...@hotmail.com escreveu: Pessoal, o postgre ele tem suporte para indices densos e esparsos? Att, Lucas José Duarte de Souza Bacharelando em Ciência da Computação Universidade Federal de Lavras. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- * *Alessandro Gonçalves Programador de Sistemas para Web ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] indices densos esparsos
2013/7/10 lucas . lucasouz...@hotmail.com Pessoal, o postgre ele tem suporte para indices densos e esparsos? Os índices no PostgreSQL são sempre densos. Logo, não possui suporte à índices esparsos. Se não me engano a única forma de se ter índices esparsos é com índices clusterizados, e o PostgreSQL não tem suporte a tal. 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] PgDAC
Boa noite, senhores. Estou fazendo a migração de um sistema de Delphi 5 para Delphi 6 e mudando os componentes de conexão TQuery para TPgQuery que faz parte do componente PgDAC da Devart. Os componentes PgDAC acabam com a camada BDE e ODBC. Sendo assim, deveria apresentar perfomance bem melhor já que serão duas camadas a menos para acessar os dados. O problema é que essa conexão PgDAC que deveria ser muito mais rápida está muito mais lenta. Como estes componentes PgDAC tem muitas propriedades, imagino que isso seja alguma configuração. Estou mudando o servidor também. Essa nova configuração está sendo montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de 600 gb RAID 1, com o PostgreSQL 9.2. Alguém que usa esse componente pode me ajudar? Att Carlos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
