Hello Tom,
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?
Thx for taking your time!
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.
regards, tom lane