On Thu, Aug 17, 2023 at 3:08 AM a.rybakina <a.rybak...@postgrespro.ru> wrote: > This is an interesting feature. I didn't notice this function before, I > studied many times consider_new_or_cause, which were called there. As far as > I know, there is a selectivity calculation going on there, but as far as I > remember, I called it earlier after my conversion, and unfortunately it > didn't solve my problem with calculating selectivity. I'll reconsider it > again, maybe I can find something I missed.
Back in 2003, commit 9888192f removed (or at least simplified) what were then called "CNF/DNF CONVERSION ROUTINES". Prior to that point the optimizer README had something about leaving clause lists un-normalized leading to selectivity estimation problems. Bear in mind that this is a couple of years before ScalarArrayOpExpr was first invented. Apparently even back then "The OR-of-ANDs format is useful for indexscan implementation". It's possible that that old work will offer some hints on what to do now. In a way it's not surprising that work in this area would have some impact on selectivies. The surprising part is the extent of the problem, I suppose. I see that a lot of the things in this area are just used by BitmapOr clauses, such as build_paths_for_OR() -- but you're not necessarily able to use any of that stuff. Also, choose_bitmap_and() has some stuff about how it compensates to avoid "too-small selectivity that makes a redundant AND step look like it reduces the total cost". It also mentions some problems with match_join_clauses_to_index() + extract_restriction_or_clauses(). Again, this might be a good place to look for more clues. -- Peter Geoghegan
