Ik was laatst aan het spelen met de resultatencache... ik weet het... dit is geen nieuwe functie en is al een tijdje beschikbaar. Helaas kan het een tijdje duren om dingen te bereiken, denk ik.
In mijn eenvoudige test had ik een vraag die dit gedrag vertoonde:
select
max(det.invoice_date)
from
invoices i
join
invoice_detail det
on i.dept_id=det.dept_id
call count cpu elapsed disk query current rows
------- ------ ------- -------- ---------- ---------- --------- ---------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 2.77 6.66 75521 75583 0 1
------- ------ ------- -------- ---------- ---------- ---------- ---------
total 4 2.77 6.67 75521 75583 0 1
75.000 schijflezingen om 1 rij te retourneren. Au! Voer dit nu door de resultatencache en krijg een aantal hele mooie cijfers.
select
/*+ result_cache */
max(det.invoice_date)
from
invoices i
join
invoice_detail det
on i.dept_id=det.dept_id
call count cpu elapsed disk query current rows
------- ------ ------ --------- ---------- ---------- ---------- ---------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 0 0 1
------- ------ ------ --------- ---------- ---------- ---------- ---------
total 4 0.00 0.00 0 0 0 1
Nog steeds 1 rij geretourneerd, maar nul schijflezingen, nul huidige blokken en in feite nul verstreken tijd. Leuk!
De resultaatcache werkt het beste wanneer een paar rijen worden geretourneerd op tabellen die niet vaak veranderen. DML-bewerkingen op de onderliggende tabellen maken het item in de resultaatcache ongeldig en het werk moet opnieuw worden uitgevoerd voordat het wordt opgeslagen in de resultaatcache.
Binnenkort, als ik de kans krijg, ga ik uitzoeken wat de impact is van bindvariabelen op query's die de resultaatcache gebruiken.