With a 'library_cache_recycle' like the recycle buffer cache. Going back to the OP - I had understood your complaint about waiting on a collision whilst searching for a match, but I had assumed it was an old problem. It seems unlikely that in an environment where you expect most of your SQL to be sharable that it would be better to give up the search for something that should be shared in order to re-optimize it. After all, you are giving up on just one latch acquisition - but a recompile could easily require you to queue for dozens of latch acquisitions - including the latch you have just given up on. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk http://www.jlcomp.demon.co.uk/faq/ind_faq.html The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/seminar.html Optimising Oracle Seminar - schedule updated May 1st ----- Original Message ----- From: "Cary Millsap" <cary.millsap@xxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Tuesday, June 08, 2004 5:51 PM Subject: RE: CBO irregularity I still think that a "don't share me" algorithm/directive for a SQL statement would be a good idea. I hadn't thought of this before, but perhaps /*+NOSHARE*/ would be a clever implementation of what I'm talking about. Cary Millsap ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------