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.
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 |