| 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: | Whole Thread | Raw Message | 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? |