Re: Slow query fixed by replacing equality with a nested query

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: val(dot)janeiko(at)gmail(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow query fixed by replacing equality with a nested query
Date: 2022-01-24 17:50:40
Message-ID: CAHOFxGpdSKdd1dP1aq+Z7hoyBXiNpRWiK747d1Y48HvLEvLs6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Jan 21, 2022 at 4:37 AM <val(dot)janeiko(at)gmail(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Lewis 2022-01-24 17:52:40 Re: Slow query fixed by replacing equality with a nested query
Previous Message Valentin Janeiko 2022-01-24 13:22:41 Re: Slow query fixed by replacing equality with a nested query