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-27 14:12:19 |
Message-ID: | CAHOFxGp8B41x0cKi-9_eEAUXVFK5UQGr-p2ANCUcRn86BU56Pw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I'm unclear what you changed to get the planner to choose one vs the other.
Did you disable hashjoins? Without the full plan to review, it is tough to
agre with any conclusion that these particular nodes are troublesome. It
might be that this was the right choice for that part of that plan, but
improper estimates at a earlier step were problematic.
What configs have you changed such as work_mem, random_page_cost, and such?
If random_page_cost & seq_page_cost are still default values, then the
planner will tend to do more seq scans I believe, and hash them to join
with large sets of data, rather than do nested loop index scans. I think
that's how that works. With the lack of flexibility to change the query,
you might be able to set a few configs for the user that runs these schema
checks. If you can find changes that make an overall improvement.
*Michael Lewis | Database Engineer*
*Entrata*
>
From | Date | Subject | |
---|---|---|---|
Next Message | tushar | 2021-09-27 15:49:31 | Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4 |
Previous Message | Andrew Dunstan | 2021-09-27 13:25:03 | Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4 |