> While you're waiting, you might think about recasting the query to
> avoid the OR. Perhaps you could do a UNION of two scans of the
> transactions table?
Thanks for the hint, I am well aware of the workaround for OR via UNION. I am not trying to improve this query per se
asit is the small root of a very complex generated query and it's unfeasible to rewrite it to a UNION in this case.
The point of my message to the list was to highlight the misestimation, which I couldn't wrap my head around. Maybe
thisdiscussion can give some food for thought to someone who might tackle this in the future. It would surely be great
tohave selectivity estimate smarts for the generic case of OR-ed SubPlans someday.
>
> > Btw, I don't quite understand why the nested loop on contract only is expected to yield 31662 rows, when the
null_fracof field transactions.contract is 1. Shouldn't that indicate zero rows or some kind of default minimum
estimatefor that query?
>
> That I don't understand. I get a minimal rowcount estimate for an
> all-nulls outer table, as long as I'm using just one IN rather than
Yeah, that might be worth digging into. Is there any other info apart from those stats that I could provide?
