Re: hashjoins, index loops to retrieve pk/ux constrains in pg12

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Arturas Mazeika <mazeika(at)gmail(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
Date: 2021-09-24 05:33:58
Message-ID: CAHOFxGpBFcz3YgLjir_zRe1qUb-uUXDV1EzqobeJcyRkOeaF2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I believe that this is a planning problem with the number of tables/joins
involved in the query you have written. If you take a look at the
definition of the views in information_schema that you are using and read
about from_collapse_limit/join_collapse_limit, you may see that this is a
bit painful for the planner. It might be cumbersome to use the actual
system tables underneath, but that would certainly lead to much better
performance. Otherwise, I would look at perhaps putting the view that has a
WHERE condition on it as the FROM to encourage the planner to perhaps
filter that set first and join the other tables after. If that didn't help,
I might even use a materialized CTE to force the issue.

Hopefully a real expert will chime in with a better explanation of the
challenges or preferred solution.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Westwood, Giles 2021-09-24 14:28:50 Performance for initial copy when using pg_logical to upgrade Postgres
Previous Message Arturas Mazeika 2021-09-23 13:00:22 hashjoins, index loops to retrieve pk/ux constrains in pg12