Re: Cache a table

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:bne9sm$kog$2$8302bc10_at_news.demon.co.uk...
>
> Note in-line
>
> --
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> The educated person is not the person
> who can answer the questions, but the
> person who can question the answers -- T. Schick Jr
>
>
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
> ____Belgium__November (EOUG event - "Troubleshooting")
> ____UK_______December (UKOUG conference - "CBO")
>
>
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> ____UK___November
>
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
>
> "Anurag Varma" <avdbi_at_hotmail.com> wrote in message
> news:E7plb.14636$4s3.2498_at_news01.roc.ny...
> >
> >
> > If a table is frequently scanned (i.e. very hot), it is going to
> remain in the
> > buffer pool no matter what. Its no good use putting it in the KEEP
> pool.
> >
>
> A little known detail about tablescans in 8.1 (and probably 9.2 but I
> don't recall confirming it) is that the touch count on blocks subject
> to tablescans is NOT increased - so even if a "small" table is loaded
> into the middle of the LRU chain and repeatedly scanned, it will
> always end up falling off the end of the LRU chain as other blocks
> are read into the buffer. It never gets promoted to the hot end unless
> it is also subject to indexed accesses.
>

Hi Jonathan,

That's a good point. Only the segment header which is read via a single block read is subject to a touch count increment during a tablescan.

And yes, it's still correct in 9.2.

Cheers

Richard Received on Sun Oct 26 2003 - 06:44:25 CST