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
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 à 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
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
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
