Re: Query slow again after adding an `OR` operation (was: Slow PostgreSQL 10.6 query)

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Behrang Saeedzadeh <behrangsa(at)gmail(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Query slow again after adding an `OR` operation (was: Slow PostgreSQL 10.6 query)
Date: 2019-10-09 19:36:00
Message-ID: CAHOFxGraNBrq9Bv1aGUJjHXZ_zAMaTK74Bewsg4qdnkTM9osNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Are you prefixing this auto generated query with set join_collapse_limit =
30, or are you changing the default and reloading config? That is, can you
impact ONLY this query with these config changes? I wouldn't assume so, so
any hack/query hint like turning off hashjoins (which seem to be chosen
instead of nested loop because of bad estimates for this plan) will likely
have serious impact on other queries.

I know you don't have the flexibility to change the query to be one that
follows best practices, but it is a bit disappointing that your ORM
generates that OR condition instead of something like *brs.branch_id IN
(query1 union all query2). *The join to branch_invoices also must function
as inner join rather than left, but I am not sure if declaring a join type
as left impacts the performance significantly.

When performance matters, there's nothing quite like being able to
customize the query directly.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2019-10-09 19:54:57 Re: Would SSD improve Index Only Scan performance by a lot?
Previous Message Jeff Janes 2019-10-09 18:42:31 Re: Modification of data in base folder and very large tables