Re: Improve hash join's handling of tuples with null join keys - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improve hash join's handling of tuples with null join keys
Date
Msg-id 616751.1755276726@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improve hash join's handling of tuples with null join keys  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
Chao Li <li.evan.chao@gmail.com> writes:
> With this patch, “isnull” now becomes true because of the change of strict op. Then the outer null join key tuple
mustbe stored in a tuplestore. When an outer table contains a lot of null join key tuples, then the tuplestore could
bumpto very large, in that case, it would be hard to say this patch really benefits. 

What's your point?  If we don't divert those tuples into the
tuplestore, then they will end up in the main hash table instead,
and the consequences of bloat there are far worse.

> Based on this patch, if we are doing a left join, and outer table is empty, then all tuples from the inner table
shouldbe returned. In that case, we can skip building a hash table, instead, we can put all inner table tuples into
hashtable.innerNullTupleStore.Building a tuplestore should be cheaper than building a hash table, so this way makes a
littlebit more performance improvement. 

I think that would make the logic completely unintelligible.  Also,
a totally-empty input relation is not a common situation.  We try to
optimize such cases when it's simple to do so, but we shouldn't let
that drive the fundamental design.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PoC: pg_dump --filter-data (like Oracle Where Clause on RMAN for specific tables)
Next
From: Benoit T
Date:
Subject: Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations