Re: hashjoins, index loops to retrieve pk/ux constrains in pg12 - Mailing list pgsql-performance

From Michael Lewis
Subject Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
Date
Msg-id CAHOFxGp8B41x0cKi-9_eEAUXVFK5UQGr-p2ANCUcRn86BU56Pw@mail.gmail.com
Whole thread Raw
In response to Re: hashjoins, index loops to retrieve pk/ux constrains in pg12  (Arturas Mazeika <mazeika@gmail.com>)
Responses Re: hashjoins, index loops to retrieve pk/ux constrains in pg12  (Arturas Mazeika <mazeika@gmail.com>)
List 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

pgsql-performance by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Next
From: tushar
Date:
Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4