Re: hashjoin chosen over 1000x faster plan - Mailing list pgsql-performance

From Tom Lane
Subject Re: hashjoin chosen over 1000x faster plan
Date
Msg-id 20980.1192039650@sss.pgh.pa.us
Whole thread Raw
In response to Re: hashjoin chosen over 1000x faster plan  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: hashjoin chosen over 1000x faster plan
Re: hashjoin chosen over 1000x faster plan
List pgsql-performance
Simon Riggs <simon@2ndquadrant.com> writes:
> Basically the planner doesn't ever optimise for the possibility of the
> never-executed case because even a single row returned would destroy
> that assumption.

It's worse than that: the outer subplan *does* return some rows.
I suppose that all of them had NULLs in the join keys, which means
that (since 8.1 or so) nodeMergejoin discards them as unmatchable.
Had even one been non-NULL the expensive subplan would have been run.

This seems like too much of a corner case to justify adding a lot of
machinery for.

            regards, tom lane

pgsql-performance by date:

Previous
From: Josh Trutwin
Date:
Subject: Re: SQL Monitoring
Next
From: "Kevin Grittner"
Date:
Subject: Re: hashjoin chosen over 1000x faster plan