Message-ID: <1834c776-cd1d-4669-89d9-5fb816acfd08@dalibo.com>
Date: Thu, 21 Dec 2023 07:27:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Which side of a Merge Join gets executed first? Do both sides
 always get executed?
Content-Language: fr, en-US
To: Jerry Brenner <jbrenner@guidewire.com>
Cc: pgsql-performance@lists.postgresql.org
References: 
 <CACoKFYQLgfOYnEGKytSZOQ7hrpdcGgk0jn22jRsZCU9aChUnCw@mail.gmail.com>
 <e7791357-4f29-4396-8419-daa14cbd52c6@dalibo.com>
 <CACoKFYQ8UH+SNuo9JaAmXeg6Z6GJiqy0xEYGbEjqnDYf6N7NoQ@mail.gmail.com>
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= <frederic.yhuel@dalibo.com>
Autocrypt: addr=frederic.yhuel@dalibo.com; keydata=
 xjMEXn3bgxYJKwYBBAHaRw8BAQdA6tX5FT/n5ztMWIoBdl6k5avvu65fv6ryfVzIx/aH3V3N
 JEYuIFlodWVsIDxmcmVkZXJpYy55aHVlbEBkYWxpYm8uY29tPsKWBBMWCAA+FiEEi7OTyf6H
 ePS+C6n11XGWhN8zGNUFAl6G6CYCGwMFCQeE3WIFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA
 CgkQ1XGWhN8zGNWH2wEA/YqoX3f4vTCknwEQgJtqWmcahkMKeusqdddqAB/jclQBAIKj3+N8
 fj3S9ZASdfUUz+PoPBvuDSSTdOqwfjX9hZkNzjgEXn3bgxIKKwYBBAGXVQEFAQEHQCuh5cLQ
 AtEBXHa2Fmtp0kduBu7msM7qO/gaEcdjFUdiAwEIB8J+BBgWCAAmAhsMFiEEi7OTyf6HePS+
 C6n11XGWhN8zGNUFAl596uUFCQeE3WIACgkQ1XGWhN8zGNVjGgEA8sKopTosiMWP+pbyf4jF
 5WphrhyQf+EBlKIAs0eOpOABAMFDjT7cnlc72KVZd79jT3zmEoVq+IUW5QhcW03LnhoN
In-Reply-To: 
 <CACoKFYQ8UH+SNuo9JaAmXeg6Z6GJiqy0xEYGbEjqnDYf6N7NoQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1834c776-cd1d-4669-89d9-5fb816acfd08%40dalibo.com>
Precedence: bulk


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 that is the
>     expensive node in our query plan
>   * The third node is the inner node in the Merge Join and that node
>     references the SubPlan generated by the first node. The IndexCond
>     has*"id = ANY($2) AND ..."* and the comparison with the result of
>     the SubPlan does not find a match, so that's where the
>     short-circuiting happens.

I think it does.

I'm not very experienced with the customs of these mailing lists, but I 
think the following would help to get more answers :

* TEXT format of EXPLAIN is much more readable (compared to JSON)
* A well formatted query would help
* Screenshots aren't so great

Rather than a screenshot, maybe you could use one of explain.depesz.com, 
explain.dalibo.com, or explain-postgresql.com ?

Best regards,
Frédéric