Re: Hash join explain is broken

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Hash join explain is broken
Дата
Msg-id 20190802070523.7se5e2wawrn646rn@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Hash join explain is broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Migowski
Дата:
Сообщение: Proposal: Clean up RangeTblEntry nodes after query preparation
Следующее
От: John Naylor
Дата:
Сообщение: Re: [proposal] de-TOAST'ing using a iterator