Re: Index compression vs. table compression

From: Richard Foote <richard.foote_at_bigpond.nospam.com>
Date: Sun, 23 Jan 2005 01:42:00 GMT
Message-ID: <IhDId.129968$K7.114981@news-server.bigpond.net.au>

Hi Howard

Comments embedded

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:csssft$ct6$1_at_news-02.connect.com.au...
> 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.
>>>
>>
>>
>> Hi Howard
>>
>> Oh dear, I see little has changed since I last had a look here ...
>
>

> 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.

Let's see if we have this right.

We're wrong in thinking you're wrong when you were really right when you wrote the wrong thing because even though it's wrong, what you meant to say was right and had you actually written the right thing instead of the wrong thing you would not have been wrong but right.

Is that right or wrong ?

The really funny thing of course is that even with your subsequent amendment, you're *still wrong* in what you say ...

>
>> 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.

What you said was quote "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".

That Howard is what *you wrote* in relation to Rick's query about the use of *cache* and it's *wrong*. Now lets put in your "amendment":

"CACHE/NOCACHE 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".

Guess what, it's still "sloppy" writing and it's still wrong...

>
>> 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.

Yes you did, *you wrote* quote "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".

And btw, even with your subsequent amendment (which wasn't mentioned at the time of my post), the above is *still wrong*.

>
>> 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]

Yes you did. From *your post* to poor Rick in this same thread dated 29/12/2004 *you said*

<quote>: "If it's a FTS, you won't want the blocks cached AT ALL, probably. And if
that's the case, holding them in cache, even for the time it takes them to age out, is *definitely* a waste of memory.

It's also the case that blocks can slip into the cold half of the LRU list which you'd rather not have flushed out. By directing FTS to their own portion of the cache, you can give such blocks a bit more time to get 're-warmed' up to the MRU end of the LRU list.

A recycle cache can be, in short, extremely useful." <end quote>.

So *you're* suggesting that RECYCLE is "extremely useful" for FTS when as I explained in the section you snipped out, this is not the case due to the fact Oracle deals with these "bad" FTS extremely efficiently in the DEFAULT pool.

Most people when they make a mistake pointed out to them something akin to "Oopps, fair enough, thanks for the correction".

Most people that is ...

Cheers

Richard Received on Sat Jan 22 2005 - 19:42:00 CST