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

From: Peter Grman <peter(dot)grman(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Bad Estimate for complex query with JOINS on subselects and OR in where conditions
Date: 2019-08-16 14:08:57
Message-ID: CACF7Wx3U_4o1EiBQzCr64u3DRXWAsJk5SxrD38KJ4hq111K=iA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Grman <peter(dot)grman(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2019-08-16 14:11:36 Re: A 3 table join question
Previous Message Luca Ferrari 2019-08-16 13:55:24 Re: Variable constants ?