From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Hash join explain is broken
In-reply-to: <20190611082220.eyhgjj47bj6jdkqp@alap3.anarazel.de>
References: 
 <CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com>
 <20190611074557.bf6wejaj6ctrjxqd@alap3.anarazel.de>
 <20190611082220.eyhgjj47bj6jdkqp@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 11 Jun 2019 01:22:20 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23549.1560465527.1@sss.pgh.pa.us>
Date: Thu, 13 Jun 2019 18:38:47 -0400
Message-ID: <23550.1560465527@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> I am too tired to look further into this. I suspect the only reason we
> didn't previously run into trouble with the executor stashing hashkeys
> manually at a different tree level with:
> ((HashState *) innerPlanState(hjstate))->hashkeys
> is that hashkeys itself isn't printed...

TBH, I think 5f32b29c is just wrong and should be reverted for now.
If there's a need to handle those expressions differently, it will
require some cooperation from the planner not merely a two-line hack
in executor startup.  That commit didn't include any test case or
other demonstration that it was solving a live problem, so I think
we can leave it for v13 to address the issue.

(But possibly we should add a test case similar to Nikita's,
so that we don't overlook such problems in future.)

			regards, tom lane