Re: pb with join plan

Поиск
Список
Период
Сортировка
От Marc Millas
Тема Re: pb with join plan
Дата
Msg-id CADX_1abVROy4x1_drTZNhgm4O9XXu02QPK-8tDktTap11zPcAg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pb with join plan  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: pb with join plan
Список pgsql-general




On Tue, Jun 20, 2023 at 10:14 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Wed, 21 Jun 2023 at 07:42, Marc Millas <marc.millas@mokadb.com> wrote:
> But if I do the same with clause one OR clause 2, I have to  kill the request after an hour, seeing the filesystem showing more than 140 Mb of increased usage.

> So, before providing the 3 explain plans (I must anonymize everything, so somewhat boring)  I would like to know if there is some obvious thing I am missing.
> all tables have been vacuum analyzed.

I believe you can anonymise the explain with https://explain.depesz.com/

link to the anonymized plan of the req with one clause : https://explain.depesz.com/s/TWp4

It's pretty hard to say until we see the query, but having an OR in
the join condition makes it impossible to Hash or Merge join, so
perhaps it's slow due to Nested Loop join.

You could consider rewriting the query to use a UNION or a UNION ALL
separating out each branch of the OR into a UNION of its own.  That
would allow Hash and Merge join to work again. However, that's all
speculation until you provide more details.

https://wiki.postgresql.org/wiki/Guide_to_reporting_problems

David


  Marc MILLAS

 

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

Предыдущее
От: Les
Дата:
Сообщение: how to return data from insert into ... on conflict ... returning ... into
Следующее
От: Lorusso Domenico
Дата:
Сообщение: foreign keys on multiple parent table