yes, I think this query is right below the geqo_threshold. But as I said, when I change only the WHERE condition to use AND instead of OR it's resulting in a really fast and efficient query (same planning time, but ~1/500th-1/1000th execution time). So there should be something different, or?
Peter Grman <peter.grman@gmail.com> writes: > our ORM with tenant separation enabled is creating the following query:
Ugh.
By my count there are nine joined tables in that query, which means you're hitting the default join_collapse_limit. Increasing that setting might improve matters somewhat, though it won't fix the bad rowcount estimate per se.
