From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Improve hash join's handling of tuples with null join keys |
Date: | 2025-08-19 00:58:47 |
Message-ID: | 659B2B36-C0FE-4642-921D-E7120E838891@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Aug 19, 2025, at 05:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>
> Yeah, we could make multi-batch PHJ do this differently from the other
> cases, but I don't want to go there: too much complication and risk of
> bugs for what is a purely hypothetical performance issue. Besides
> which, if the join is large enough to be worth worrying over, it's
> most likely taking that code path anyhow.
>
>
>> We can simply added a new flag to HashTable, say named skip_building_hash. Upon right join (join to the hash side), and outer table is empty, set the flag to true, then in the MultiExecPrivateHash(), if skip_building_hash is true, directly put all tuples into node->null_tuple_store without building a hash table.
>> Then in ExecHashJoinImpl(), after "(void) MultiExecProcNode()" is called, if hashtable->skip_building_hash is true, directly set node->hj_JoinState = HJ_FILL_INNER_NULL_TUPLES.
>
> I'm not excited about this idea either. It's completely abusing the
> data structure, because the "null_tuple_store" is now being used for
> tuples that (probably) don't have null join keys. The fact that you
> could cram it in with not very many lines of code does not mean that
> the result will be understandable or maintainable --- and certainly,
> hash join is on the hairy edge of being too complicated already.
>
> regards, tom lane
Thanks for the explanation. Then these two comments are resolved.
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-08-19 01:00:37 | Re: Remove useless pointer advance in StatsShmemInit() |
Previous Message | Michael Paquier | 2025-08-19 00:28:12 | Re: make -C src/test/isolation failure in index-killtuples due to btree_gist |