Re: Slow query fixed by replacing equality with a nested query - Mailing list pgsql-performance

From Michael Lewis
Subject Re: Slow query fixed by replacing equality with a nested query
Date
Msg-id CAHOFxGpdSKdd1dP1aq+Z7hoyBXiNpRWiK747d1Y48HvLEvLs6g@mail.gmail.com
Whole thread Raw
In response to RE: Slow query fixed by replacing equality with a nested query  (<val.janeiko@gmail.com>)
List pgsql-performance
On Fri, Jan 21, 2022 at 4:37 AM <val.janeiko@gmail.com> wrote: 

I have done a few simple experiments in the past comparing CTEs like this to JOINS, but the resultant query plans were the same. CTEs seemed easier to follow when troubleshooting issues, so I left them as such. Do JOINs become better than CTEs at a certain point?


Read up on from_collapse_limit. If the query can re-write subqueries to collapse the join problem, then it will at first but then once it reaches that threshold, then it won't try anymore to avoid excessive planning time. That's when things can go awry.

pgsql-performance by date:

Previous
From: Valentin Janeiko
Date:
Subject: Re: Slow query fixed by replacing equality with a nested query
Next
From: Michael Lewis
Date:
Subject: Re: Slow query fixed by replacing equality with a nested query