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 where all
> of the time is spent.
>
> On the surface, I don't see any way from the attached explain plan to
> determine which side of the Merge Join is executed first. Some questions:
>
> * Which side gets executed first?
> * How would one tell that from the json?
> * Have there been any relevant changes to later releases to make that
> more apparent?
> * 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?
>
> Here's a screenshot from pgMustard.
>
> * Nodes 6 and 14 (the first node under each of the Merge Joins) each
> return 0 rows
> * Nodes 9 and 15 are the expensive sides of the Merge Joins and return
> lots of rows
I think those nodes (9 and 15) are expensive because they have to filter
out 8 millions rows in order to produce their first output row. After
that, they get short circuited.
Best regards,
Frédéric