Re: Hash join explain is broken - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Hash join explain is broken
Date
Msg-id 20190802070523.7se5e2wawrn646rn@alap3.anarazel.de
Whole thread Raw
In response to Re: Hash join explain is broken  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2019-07-02 10:50:02 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> Tom, any comments? Otherwise I'll go ahead, and commit after a round or
> >> two of polishing.
> 
> > Sorry for not getting to this sooner --- I'll try to look tomorrow.
> 
> I took a look, and I think this is going in the right direction.
> We definitely need a test case corresponding to the live bug,
> and I think the comments could use more work, and there are some
> cosmetic things (I wouldn't add the new struct Hash field at the
> end, for instance).

I finally pushed a substantially polished version of this. I ended up
moving, as I had wondered about, hashoperator and hashcollation
computation to the planner too - without that we would end up with two
very similar loops during plan and execution time.

I've added a test that puts subplans just about everywhere possible in a
hash join - it's the only reliable way I found to trigger errors (only
during EXPLAIN, as deparsing there tries to find the associated node,
for column names etc, and failed because the subplan referenced an
INNER_VAR, even though Hash doesn't have an inner plan). Makes the test
query a bit hard to read, but I didn't get any better ideas, and it
doesn't seem too bad.

Thanks Tom for the review, thanks Alexander and Nikita for the
report. Sorry that it took this long.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Daniel Migowski
Date:
Subject: Proposal: Clean up RangeTblEntry nodes after query preparation
Next
From: John Naylor
Date:
Subject: Re: [proposal] de-TOAST'ing using a iterator