From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | Jerry Brenner <jbrenner(at)guidewire(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Which side of a Merge Join gets executed first? Do both sides always get executed? |
Date: | 2023-12-20 18:05:40 |
Message-ID: | 7a5deb77-3607-4252-be85-63ed0093d9fb@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Frédéric Yhuel | 2023-12-20 18:32:47 | Re: Which side of a Merge Join gets executed first? Do both sides always get executed? |
Previous Message | Jerry Brenner | 2023-12-20 14:40:48 | Which side of a Merge Join gets executed first? Do both sides always get executed? |