From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Hash join explain is broken
Date: Thu, 13 Jun 2019 18:38:47 -0400
Message-ID: <23550.1560465527@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, a.korotkov@postgrespro.ru
Subject: Re: Hash join explain is broken
In-Reply-To: <23550.1560465527@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox