From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | Jerry Brenner <jbrenner(at)guidewire(dot)com> |
Cc: | 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-21 06:27:20 |
Message-ID: | 1834c776-cd1d-4669-89d9-5fb816acfd08@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Darwin Correa | 2023-12-26 02:49:40 | Slow GroupAggregate and Sort |
Previous Message | Jerry Brenner | 2023-12-20 19:04:28 | Re: Which side of a Merge Join gets executed first? Do both sides always get executed? |