Thread: Hash join explain is broken
Hi!
After 5f32b29c explain of Hash Join sometimes triggers an error.
Simple reproduction case is below.
# create table t (x int);
CREATE TABLE
# set enable_sort = off;
SET
# explain select * from t a, t b where a.x = (select 1 where b.x = 1);
ERROR: bogus varno: 65000
Before 5f32b29c the same case works OK.
# explain select * from t a, t b where a.x = (select 1 where b.x = 1);
QUERY PLAN
-------------------------------------------------------------------
Hash Join (cost=67.38..5311.24 rows=32512 width=8)
Hash Cond: (a.x = (SubPlan 1))
-> Seq Scan on t a (cost=0.00..35.50 rows=2550 width=4)
-> Hash (cost=35.50..35.50 rows=2550 width=4)
-> Seq Scan on t b (cost=0.00..35.50 rows=2550 width=4)
SubPlan 1
-> Result (cost=0.00..0.01 rows=1 width=4)
One-Time Filter: (b.x = 1)
(8 rows)
Originally spotted by Nikita Glukhov. I didn't investigate this case
further yet.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi, On 2019-06-10 21:28:12 +0300, Alexander Korotkov wrote: > After 5f32b29c explain of Hash Join sometimes triggers an error. > > Simple reproduction case is below. Thanks for finding. I've created an open issue for now. Greetings, Andres Freund
Hi, On 2019-06-11 00:45:57 -0700, Andres Freund wrote: > On 2019-06-10 21:28:12 +0300, Alexander Korotkov wrote: > > After 5f32b29c explain of Hash Join sometimes triggers an error. > > > > Simple reproduction case is below. > > Thanks for finding. I've created an open issue for now. 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... If done properly, the expression would actually reside in the Hash node itself, rather than ExecInitHashJoin() splitting up the join condition itself, and moving it into the HashState. Greetings, Andres Freund
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
Hi, On June 13, 2019 3:38:47 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >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. I'm pretty sure you'd get an assertion failure if you reverted it (that's why it was added). So it's a bit more complicatedthan that. Unfortunately I'll not get back to work until Monday, but I'll spend time on this then. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi, On 2019-06-13 16:23:34 -0700, Andres Freund wrote: > On June 13, 2019 3:38:47 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >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. > > I'm pretty sure you'd get an assertion failure if you reverted it > (that's why it was added). So it's a bit more complicated than that. > Unfortunately I'll not get back to work until Monday, but I'll spend > time on this then. Indeed, there are assertion failures when initializing the expression with HashJoinState as parent - that's because when computing the hashvalue for nodeHash input, we expect the slot from the node below to be of the type that HashState returns (as that's what INNER_VAR for an expression at the HashJoin level refers to), rather than the type of the input to HashState. We could work around that by marking the slots from underlying nodes as being of an unknown type, but that'd slow down execution. I briefly played with the dirty hack of set_deparse_planstate() setting dpns->inner_planstate = ps for IsA(ps, HashState), but that seems just too ugly. I think the most straight-forward fix might just be to just properly split the expression at plan time. Adding workarounds for things as dirty as building an expression for a subsidiary node in the parent, and then modifying the subsidiary node from the parent, doesn't seem like a better way forward. The attached *prototype* does so. If we go that way, we probably need to: - Add a test for the failure case at hand - check a few of the comments around inner/outer in nodeHash.c - consider moving the setrefs.c code into its own function? - probably clean up the naming scheme in createplan.c I think there's a few more things we could do, although it's not clear that that needs to happen in v12: - Consider not extracting hj_OuterHashKeys, hj_HashOperators, hj_Collations out of HashJoin->hashclauses, and instead just directly handing them individually in the planner. create_mergejoin_plan() already partially does that. Greetings, Andres Freund PS: If I were to write hashjoin today, it sure wouldn't be as two nodes - it seems pretty clear that the boundaries are just too fuzzy. To the point that I wonder if it'd not be worth merging them at some point.
Attachment
Hi, On 2019-06-18 00:00:28 -0700, Andres Freund wrote: > On 2019-06-13 16:23:34 -0700, Andres Freund wrote: > > On June 13, 2019 3:38:47 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >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. > > > > I'm pretty sure you'd get an assertion failure if you reverted it > > (that's why it was added). So it's a bit more complicated than that. > > Unfortunately I'll not get back to work until Monday, but I'll spend > > time on this then. > > Indeed, there are assertion failures when initializing the expression > with HashJoinState as parent - that's because when computing the > hashvalue for nodeHash input, we expect the slot from the node below to > be of the type that HashState returns (as that's what INNER_VAR for an > expression at the HashJoin level refers to), rather than the type of the > input to HashState. We could work around that by marking the slots from > underlying nodes as being of an unknown type, but that'd slow down > execution. > > I briefly played with the dirty hack of set_deparse_planstate() > setting dpns->inner_planstate = ps for IsA(ps, HashState), but that > seems just too ugly. > > I think the most straight-forward fix might just be to just properly > split the expression at plan time. Adding workarounds for things as > dirty as building an expression for a subsidiary node in the parent, and > then modifying the subsidiary node from the parent, doesn't seem like a > better way forward. > > The attached *prototype* does so. > > If we go that way, we probably need to: > - Add a test for the failure case at hand > - check a few of the comments around inner/outer in nodeHash.c > - consider moving the setrefs.c code into its own function? > - probably clean up the naming scheme in createplan.c > > I think there's a few more things we could do, although it's not clear > that that needs to happen in v12: > - Consider not extracting hj_OuterHashKeys, hj_HashOperators, > hj_Collations out of HashJoin->hashclauses, and instead just directly > handing them individually in the planner. create_mergejoin_plan() > already partially does that. Tom, any comments? Otherwise I'll go ahead, and commit after a round or two of polishing. - Andres
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.
regards, tom lane
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).
regards, tom lane
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