Re: Index compression vs. table compression

Richard Foote wrote:
> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:41d3480c$0$1084$afc38c87_at_news.optusnet.com.au...
>

>>Rick Denoire wrote:
>>[snip]
>>
>>
>>>That reminds me the "cache" option for tables, I also never understood
>>>how that could go well. Nowadays, Oracle discourages its use.
>>
>>No they don't. They say that it is unnecessary and less effective than the 
>>multiple buffer pools feature you seem not quite to grasp properly. CACHE 
>>was an attempt to keep large full table scans at the cold end of the LRU 
>>list, and thus prevent the warm half from being flushed out. Precisely 
>>what the RECYCLE pool does. Only the RECYCLE pool does the job more 
>>effectively and more certainly, because it's not trying to 'partition' a 
>>single LRU list, but has one all to itself.
>>

You're right. You're still posting nit-picky stuff that contributes so little actual enlightenment. One would almost think it were personal...

> For someone who demands so much "precision" from others,

I demand nothing. I expect precision in this subject, because without it, we're lost. If you find precision in this subject-matter so much of an imposition, you are welcome to resort to the usual Bowie-laden vagueness we're used to.

And, merely incidentally I realise, but the need for precision does not demand a commensurate measure of papal-like infallibility. Mistakes and imprecision are two different things.

> it's been a while
> since I last read such *imprecise* contributions.

Not imprecise. Missing one word and a slash. Where you read, eagerly, "CACHE", try reading "CACHE/NOCACHE". The one without the other is meaningless, and I would have hoped you would have realised that. But clearly my expectations are excessive in such matters.

> Others have pointed out
> some of your errors and inconsistencies

No, they haven't. Jonathan mentioned a detail about the way the LRU list actually works. A detail which I could have mentioned but didn't, because it is not germane to the discussion, and changes nothing. Don't tell me that in all those many years teaching people in Canberra and elsewhere that you never *simplified*, even *over* simplified, to make your point, because I won't believe you.

> but if I can just go back to this
> little piece and clarify things a little for the benefit of Rick and others
> you've confused.
>
> CACHE was an attempt to keep FTS at the *hot end* of the LRU list,

CACHE/NOCACHE was an attempt to separate out useful FTS from bad FTS. And whether you view that from the hot or cold end is irrelevant. The point is to "partition" the LRU list. Which is what I said, and which was correct.

> not the
> cold end, although as Jonathan has pointed out, Oracle no longer puts blocks
> at the "end". So the above is incorrect. The idea of "caching" something in
> memory is to "keep" something in memory and this is the purpose of the
> "KEEP" pool.

Stone me. And there was me thinking the word "keep" meant, er, "dispose of". Not.

> So CACHE and KEEP kinda compliment each other (not CACHE and RECYCLE as
> incorrectly stated above)

I didn't state that. So don't say I did.

> although blocks that are "CACHE"D have a rather
> hard time of staying cached due to the way Oracle's touch count mechanism
> discriminates against them. However blocks that are placed in the KEEP pool
> can remain cached with some assurance, *if* the size of the KEEP pool is
> larger than the sum of the size of all KEEP objects. The danger with the
> KEEP pool though is that you "keep" and allocate resources to an object that
> could be better utilised elsewhere.

> So yes Rick, you are correct and Howard was somewhat imprecise (dead wrong)
> in what he said above and in his earlier post to you regarding FTS wasting
> memory and pushing out blocks.

I missed out a word and a slash, incorrectly assuming that my audience would be switched on enough to add them in for themselves. I apologise for over-estimating the intelligence of this little corner of my audience.

> And Rick, just to clarify another error of Howard's,

[snip an interesting contribution nevertheless based on the assumption that I actually said anything of the sort]

HJR Received on Sat Jan 22 2005 - 00:39:53 CST