Search Postgresql Archives

Re: Bad Estimate for complex query with JOINS on subselects and OR in where conditions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

On Fri, Aug 16, 2019 at 3:44 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Peter Grman <peter.grman@xxxxxxxxx> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux