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-06-13 23:23:34
Message-ID: 93FA6FE5-03C5-4AB1-B0D8-C1FA00C72121@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On June 13, 2019 3:38:47 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)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.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-06-13 23:45:18 Re: Parallel grouping sets
Previous Message Thomas Munro 2019-06-13 23:00:30 Obsolete comments about semaphores in proc.c