Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira < [email protected]> escreveu: > > ... [corte] ... > > > --=========== Como acredito que você irá resolver seu problema, seque considerações > > O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn) (Filter: ((gn)::text = '9000000'::text)) para atender o tipo de argumento da FUNCTION que era do tipo text e no caso a coluna que ele comparava era do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que um campo tipo char, houve então o CAST implícito pelo PostgreSQL e com isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois o índice não atendia para esse caso. >
Show de bola Ronaldo... excelente análise e retorno... é por esse tipo de "cuidado" e "dedicação" sem compromisso que nunca deixo de acreditar em comunidades. Só por favor evite o top-posting. > --=========== -->> Sugestões: > > 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para entender melhor o problema? > > 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna, para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou chave_acesso > > 3 - Caso não tenha como mudar o tipo do argumento da FUNCTION, então realizar o CAST explicito na variável (chave) no corpo FUNCTION na linha ( PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;) > > Ex: PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave::bpchar; > > 4 - Executar e nos passar o resultado > > Ótimo... e pior é que esse tipo de equívoco é mais comum do que parece e nos passou totalmente desapercebido... porém lá no início da thread deveriamos ter mais informações como a estrutura das tabelas envolvidas então todos consideraram que os tipos de dados eram iguais e que outro problema deveria estar ocorrendo... mas novamente nós como "seres humanos" tendenciamos a complicar as coisas ao invés de simplificar. Se puder depois @Alexsander dar um feedback, caso a sugestão do Ronaldo ajudou para ai termos um bom histórico na nossa lista de discussão para consultas futuras. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
