The attached query plan is from 11.
We are getting Merge Joins on both sides of the UNION. In both cases, the
first node under the Merge Join returns 0 rows but the other side of the
Merge Join (the one being sorted) is executed and that's where all of the
time is spent.
On the surface, I don't s
Le 20/12/2023 à 15:40, Jerry Brenner a écrit :
The attached query plan is from 11.
We are getting Merge Joins on both sides of the UNION. In both cases,
the first node under the Merge Join returns 0 rows but the other side of
the Merge Join (the one being sorted) is executed and that's wher
Le 20/12/2023 à 15:40, Jerry Brenner a écrit :
Whichever side gets executed first, is the execution of the side that
would be second get short circuited if 0 rows are returned by the first
side?
Indeed, if 0 rows are returned from the outer relation, the scan of the
inner relation is never
Thanks. Does this make sense?
- There are 3 nodes under the Merge Join
- The first node is an InitPlan, due to the ANY(ARRAY()) - that gets
executed and finds 0 matching rows
- The second node is the outer node in the Merge Join and that is the
expensive node in our query plan
-
Le 20/12/2023 à 20:04, Jerry Brenner a écrit :
Thanks. Does this make sense?
* There are 3 nodes under the Merge Join
* The first node is an InitPlan, due to the ANY(ARRAY()) - that gets
executed and finds 0 matching rows
* The second node is the outer node in the Merge Join and th
