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 CAHOFxGoOz4RYH2Zj9C6EqcqLKKTwv=76onrOK0_DJGC8Fhu8vQ@mail.gmail.com
Whole thread Raw
In response to Slow query fixed by replacing equality with a nested query  (Valentin Janeiko <val.janeiko@gmail.com>)
Responses RE: Slow query fixed by replacing equality with a nested query  (<val.janeiko@gmail.com>)
List pgsql-performance
I don't see any reference to cte1. Is that expected?

I'm unclear why these sets are not just inner join'd on resource_surrogate_id. It seems like that column it is being selected as Sid1 in each CTE, and then the next one does the below. Why?

where resource_surrogate_id IN (SELECT Sid1 FROM cte_previous_number)

pgsql-performance by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: PostgreSQL and Linux CPU's
Next
From:
Date:
Subject: RE: Slow query fixed by replacing equality with a nested query