I'll second that suggestion! To extend the analogy, how about a "recycle pool" for them? (So they don't fragment or otherwise clutter up the "keep pool".) How about adaptive "auto-pin" in the "keep pool" based on execution frequency? (Never mind... Probably not really necessary. I'd settle for the LRU bias.)
Don Granaman [OraSaurus] ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 11:03 PM I think an excellent Oracle kernel enhancement would be to bias in the LRU scheme against SQL that uses literals, just like the buffer cache algorithm biases against blocks that are read via full-table scan. Think about it... What's the likelihood that a SQL statement that's filthy with literal values will ever be reused again in the future? Then why store it as if it will ever be shared (i.e., reused) in the future? Cary Millsap Hotsos Enterprises, Ltd. [EMAIL PROTECTED] http://www.hotsos.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
