--- Osvaldo Kussama <[EMAIL PROTECTED]>
escreveu:
> Gaspar von Scharten <[EMAIL PROTECTED]>
> escreveu: Thiago :
>
> A solução efetiva não é bem esta. O
> problema é que você está fazendo um "count" .
>
> <<<SELECT INTO res COUNT(cpf) as num_cpf
> <<<FROM candidato WHERE cpf = ncpf AND id_candidato
> != id_cand;
>
> Mesmo com índice parcial o postgres vai
> acessar mais registros do que é necessário !
>
> O melhor seria fazer alguma coisa
> parecida com :
>
> IF new.cpf is not null THEN
> IF EXISTS(select 1 from candidato
> where new.cpf= cpf ) THEN
> RAISE EXCEPTION
> ..............................
>
>
>
>
>
> Gaspar at inforep.com.br
> Você considerou a possibilidade de
> criação de um índice parcial?
>
> CREATE UNIQUE INDEX seu_indice_parcial ON candidato
> (ncpf)
> WHERE (ncpf != '' AND ncpf
> NOTNULL);
>
>
> []s
>
> Osvaldo
>
>
> P.S. Isto não ajudará nos "UPDATES GERAIS".
> Avalie com um EXPLAIN ANALYZE o plano de execução de
> um update sem cláusula where.
>
>
>
>
> Creio que a criação de um índice UNIQUE como
> sugerido acima é efetiva pois qualquer tentativa de
> inclusão de um cpf já existente, ou alteração para
> um cpf já existente, provocaria um erro no comando,
> não havendo necessidade, portanto, da trigger para
> verificar a existência do cpf, o próprio PostgreSQL
> cuidaria disso.
>
> []s
> Osvaldo
>
>
>
Se quiser continuar com a trigger, vc poderia por
dentro dela um código como o seguinte:
PERFORM cs_log('Atualizando o registro '||
NEW.<chave_primaria>);
Da um
tail -f <arquivo_de_log>
executa a query problematica e observa se ela travou
mesmo ou eh demorada (acho mais provavel) observando a
saida do arquivo de log.
_______________________________________________________
Abra sua conta no Yahoo! Mail: 1GB de espaço, alertas de e-mail no celular e
anti-spam realmente eficaz.
http://mail.yahoo.com.br/
_______________________________________________
Grupo de Usuários do PostgreSQL no Brasil
http://www.postgresql.org.br
