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

Поиск
Список
Период
Сортировка
От Michael Lewis
Тема Re: Query slow again after adding an `OR` operation (was: SlowPostgreSQL 10.6 query)
Дата
Msg-id CAHOFxGraNBrq9Bv1aGUJjHXZ_zAMaTK74Bewsg4qdnkTM9osNw@mail.gmail.com
обсуждение исходный текст
Ответ на Query slow again after adding an `OR` operation (was: Slow PostgreSQL10.6 query)  (Behrang Saeedzadeh <behrangsa@gmail.com>)
Список 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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Modification of data in base folder and very large tables
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Would SSD improve Index Only Scan performance by a lot?