Re: Re: Suspicious call of initial_cost_hashjoin()
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Antonin Houska <ah@cybertec.at>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-01T19:45:22Z
Lists: pgsql-hackers
Hi Antonin, On 12/22/17 6:13 AM, Thomas Munro wrote: > On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska <ah@cybertec.at> wrote: >> try_partial_hashjoin_path() passes constant true to for the parallel_hash >> argument of initial_cost_hashjoin(). Shouldn't it instead pass the >> parallel_hash argument that it receives? > > Thanks. Yeah. When initial_cost_hashjoin() calls > get_parallel_divisor() on a non-partial inner path I think it would > return 1.0, so no damage was done there, but when > ExecChooseHashTableSize() receives try_combined_work_mem == true it > might underestimate the number of batches required for a partial hash > join without parallel hash, because it would incorrectly assume that a > single batch join could use the combined work_mem budget. This was > quite well hidden because ExecHashTableCreate() calls > ExecChooseHashTableSize() again (rather than reusing the results from > planning time), so the bad nbatch estimate doesn't show up anywhere. Does this look right to you? If so, can you sign up as a reviewer and mark it Ready for Committer? Thanks, -- -David david@pgmasters.net
Commits
-
Fix costing of parallel hash joins.
- 5b804cc168a5 11.0 landed
-
Add parallel-aware hash joins.
- 1804284042e6 11.0 cited