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

>

In response to

Responses

Browse pgsql-performance by date

  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