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.
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 |