Re: Hash join explain is broken

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash join explain is broken
Date: 2019-08-02 07:05:23
Message-ID: 20190802070523.7se5e2wawrn646rn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-07-02 10:50:02 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2019-08-02 07:12:20 Re: [proposal] de-TOAST'ing using a iterator
Previous Message Daniel Migowski 2019-08-02 07:01:26 Proposal: Clean up RangeTblEntry nodes after query preparation