Performance do pi-reposiciona-query em cadastro pai x filho

Boa tarde, pessoal

Tenho um programa de cadastro pai x filho, básico, nada complexo, mas que tá me dando uma certa dor de cabeça.

O usuário clica no botãozinho "novo", informa os dados da tabela "pai" (cerca de 7 campos) e, quando clica no botão "ok" da tela, o sistema passa por um delayzinho de uns 6 segundos e, então, fecha o cadastro "pai" e abre o programa de cadastro dos filhos. Esse delay de 6 segundos tá gerando burburinhos na empresa, porque 1) o usuário diz que inicialmente não existia tanto delay (o que me leva a crer que tem relação direta com a quantidade crescente de dados na tabela e, consequentemente, índice problemático) e 2) os usuários dizem que leva mais tempo esperar abrir o cadastro filho após botão OK do que o próprio cadastro pai.

Verifiquei que o código do botão OK do cadastro pai tem apenas 2 linhas:

Código:

{include/okpai.i h_v01rs001}
RUN pi-roda-filho IN h-handle-pai.

Coloquei uns messages com etime nesse código e identifiquei que a include okpai é a que sofre desse delay.

Consegui o código da include/okpai.i, conforme abaixo:

Código:

do  on error undo, return no-apply:
  RUN dispatch IN {1}('update-record':U).
  IF return-value = "ADM-ERROR":U THEN
     RETURN NO-APPLY.
  RUN dispatch IN wh-query ('open-query':U).
  RUN get-rowid IN {1}
      (OUTPUT v-row-table).
  RUN pi-reposiciona-query IN wh-query
      (INPUT v-row-table).
  apply "close":U to this-procedure.
end. 

e identifiquei que há 2 picos de delay: no dispatch do update-record (de, hoje, média de 1422 milissegundos) e no pi-reposiciona-query (com 2312 milissegundos).

Entendo (e é nisso, também, que eu gostaria da ajuda dos amigos em fazer a análise) que até é coerente o tempo do update-record, mas não entendo/aceito a demora no pi-reposiciona-query.

A tabela pai tinha apenas uma chave primária: cod-emitente, nro-docto e nat-operacao, enquanto que a query criada para o cadastro fazia um "by dt-trans". Criei, então, um índice com dt-trans (só isso), achando que resolveria/ajudaria -- mas nada.

Pergunto, então: há, dentre minhas ações, alguma coisa que eu não tenha feito a contento? Ou há alguma coisa a mais a fazer/customizar pra acelerar esse pi-reposiciona-query?

Grande Eugênio, valeu pela atenção.

Olhei e vi que essa opção não estava marcada. Marquei o INDEXED-REPOSITION, ativei minhas msgs com etime e fui pro teste. Olha só a comparação, feita agora:

SEM INDEXED-REPOSITION:

• update-record: 1453 milissegundos
  wh-query: 16 milissegundos
  pi-reposiciona-query: 2266 milissegundos

COM INDEXED-REPOSITION:

• update-record: 1422 milissegundos
  wh-query: 16 milissegundos
  pi-reposiciona-query: 564 milissegundos

Bah! Que maravilha, cara. Parece que era isso mesmo.

Brigadão mesmo pela atenção.

Forte abraço e sucesso!

--
TOSHYRO