A MINUS is een set-bewerking die, naast het wegnemen van de resultaten van de tweede zoekopdracht van de eerste, ook duplicaten verwijdert als ze in de eerste set voorkomen. Als zodanig zal de getoonde zoekopdracht altijd de volledige resultatenset moeten bouwen van TABLE_1 voordat u het terugstuurt naar de gebruiker.
Als u er zeker van kunt zijn dat er geen duplicaten zijn voor de trimemd-kop/ingangsdatum in de eerste set (of als u niet wilt dat dergelijke duplicaten worden verwijderd), kunt u proberen
SELECT RTRIM(LTRIM(A.HEAD)), A.EFFECTIVE_DATE,
FROM TABLE_1 A
WHERE A.TYPE_OF_ACTION='6'
AND A.EFFECTIVE_DATE >= ADD_MONTHS(SYSDATE,-15)
AND NOT EXISTS
(select 1 from table_2 b
where RTRIM(LTRIM(b.head)) = RTRIM(LTRIM(a.head))
and b.effective_date = a.effective_date) )
Op die manier kan de query veel sneller resultaten opleveren, vooral als table_2 erg klein is of als de rijen toegankelijk zijn via een index op effectieve_datum of head.
ps. Verwijder indien mogelijk de RTRIM(LTRIM())-bits.
PPS. Er is nog steeds geen garantie dat het binnen 8 seconden terugkeert. Dat hangt af van hoe groot table_1 is, en indexen op type_of_action en/of effectieve_date.
Toegevoegd:
Je zou kunnen bladeren door
SELECT RTRIM(LTRIM(A.HEAD)), A.EFFECTIVE_DATE,
FROM TABLE_1 A
WHERE A.TYPE_OF_ACTION='6'
AND A.EFFECTIVE_DATE >= ADD_MONTHS(SYSDATE,-15)
en negeer rijen als het terugkwam
select 1 from table_2 b
where RTRIM(LTRIM(b.head)) = :1
and b.effective_date = :1
and rownum =1
Maar het zou zeker langer duren om het volledig uit te voeren. Misschien orden van grootte langer (dwz uren), afhankelijk van hoe lang elke table_2-controle duurt. Ik weet niet precies welke criteria worden gebruikt voor de cutoff (duur van de oproep of de duur van de open SQL-cursor), dus het kan de buitenste cursor sluiten. En afhankelijk van de grootte/index/inhoud van table_1, kan de buitenste cursor nog steeds niet de eerste rijen binnen het tijdsbestek retourneren.
Hoeveel rijen in table_1, table_2 en welke indexen zijn beschikbaar?