Bom, sem nenhuma análise muito profunda (só uma passada de vista), o que
parece é que quando vc faz o CASE vc está acessando dados da tabela C e ** não
** usa em lugar nenhum mais do SELECT dados da tabela ST, ENQUANTO na versão
sem CASE vc faz referência direta às colunas da ST no SELECT via
,ST.DESCR_STATUS AS DESCR_STATUS : assim sendo, a impressão que temos é que o
acesso à essa tal ST é que está causando mais demora, TALVEZ por estatísticas
de má qualidade nessa tabela/coluna... Obtenha um plano de execução COMPLETO
para as duas versões, ** inclusive ** com as colunas A-ROWS e E-ROWS para se
poder avaliar o estimado e o obtido, SE houver diferença gritante
estatisticamente entre os dois, se pode chutar mesmo estatísticas incompletas,
falta ou aumento de buckets no histograma, por aí...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Rafael Mendonca <raffaell.ti77@...>
escreveu
>
> Pessoal, bom dia.
>
> Achei um caso estranho em uma query, na segunda coluna do SELECT, quando eu a
> coloco para retornar o valor da tabela, a consulta demora bastante...
>
> Mas quando eu substituo a segunda coluna por um CASE, ela me traz na
> velocidade de uma bala, alguém saberia explicar o motivo ?
>
> Estou com esse probleminha, tentando ajustar a query sem o CASE, só que
> quando executo a consulta, demora em torno de 2 minutos.
>
> Segue a query sem o CASE e seu plano de execução:
>
> http://sql.nopaste.dk/p21339
>
>
> Segue a query com o CASE e seu plano de execução:
>
> http://sql.nopaste.dk/p21340
>
>
> Obs: me refiro a segunda coluna do SELECT "DESCR_STATUS"
>
> Já tentei criar um índice para as 2 colunas do filtro da tabela MOVIMENTO_SSF
>
> que melhorou em torno de 30 segundos, mas eu acho que não seja a solução.
>
> SELECT Count(*) FROM MOVIMENTO_SSF -- 2.456.384 registros
> SELECT Count(*) FROM STATUS_PESSOA -- 9 registros
>
> [As partes desta mensagem que não continham texto foram removidas]
>
