On Mon, Jan 24, 2022 at 6:22 AM Valentin Janeiko
wrote:
> I have rewritten the query using JOINs. I had to make one of them a
> FULL JOIN, but otherwise JOINs seem like a good idea.
> I have added the new query to the (same) gist:
>
> https://gist.github.com/valeneiko/89f8cbe26db7ca2651b47524462b
On Fri, Jan 21, 2022 at 4:37 AM 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 c
I have rewritten the query using JOINs. I had to make one of them a
FULL JOIN, but otherwise JOINs seem like a good idea.
I have added the new query to the (same) gist:
https://gist.github.com/valeneiko/89f8cbe26db7ca2651b47524462b5d18#file-queryoptimized-sql
The query plan is much better with just
My mistake. I have updated the query in the gist: cte1 should have been
referenced in cte2.
The query plans are correct. It was just the query in the gist that was
incorrect (I was just verifying cte1 was the culprit – without it the query is
fast too).
This SQL query is a result of transl
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_p
Hi everyone,
I have a SELECT query that uses a chain of CTEs (4) that is slow to run on
a large
database. But if I change a where clause in one of the small CTEs from an
equality to an equivalent nested IN query, then the query becomes fast.
Looking
at the query plan I can see that after the chang
