RE: bloom filter not used after 19C upgrade
Date: Thu, 9 May 2024 08:51:00 -0400
Message-ID: <10be01daa20f$8be39d10$a3aad730$_at_rsiz.com>
You wrote:
“In 10053 KkoBloomFIlter messages are: accepted, but final decision will be made in code generation. But in the final execution plan it is using partition range all..”
I believe this means that the CBO has determined that a bloom filter plan is valid and possibly is cheaper.
Unfortunately, and this is a pet peeve of mine, there is no way to influence Oracle to make the “opposite” choice at code generation. (Code generation could probably be better described. If someone has a good doc, please advise.)
This is sad, because it robs both you and Oracle of feedback whether the decision that was made resulted in a better elapse time and amount of resource consumption. Even a “do it both ways” flag with instructions where to fork the results would be superior (for diagnostics, no, I’m not suggesting you do it both ways forever.)
Did you notice because the only reason you notices it stopped actually using bloom filters was because it ran significantly slower, or were you examining this query for some other reason?
Good luck,
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Laurentiu Oprea
Sent: Wednesday, May 08, 2024 3:43 PM
Dear all,
I`m trying to figure out why a query is not using part join bloom filter after the 19C upgrade.
In 10053 KkoBloomFIlter messages are: accepted, but final decision will be made in code generation. But in the final execution plan it is using partition range all..
WHere should I look for hints to understand what exactly went wrong?
Appreciate your help.
To: ORACLE-L (oracle-l_at_freelists.org)
Subject: bloom filter not used after 19C upgrade
--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 09 2024 - 14:51:00 CEST