On 3/2/18 05:01, Thomas Munro wrote:
> On Fri, Mar 2, 2018 at 9:06 PM, Antonin Houska wrote:
>> David Steele wrote:
>>> Does this look right to you?
>>
>> Yes, this is what I meant. The patch applies cleanly and the code compiles
>> well.
>>
>>> If so, can you sign up as a reviewer and mark it Re
On Fri, Mar 2, 2018 at 9:06 PM, Antonin Houska wrote:
> David Steele wrote:
>> Does this look right to you?
>
> Yes, this is what I meant. The patch applies cleanly and the code compiles
> well.
>
>> If so, can you sign up as a reviewer and mark it Ready for Committer?
>
> Done.
Thanks.
> Actua
David Steele wrote:
> On 12/22/17 6:13 AM, Thomas Munro wrote:
> > On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska 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 arg
Hi Antonin,
On 12/22/17 6:13 AM, Thomas Munro wrote:
> On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska 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 recei
On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska 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
ge
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?
This is related to commit 1804284042e659e7d16904e7bbb0ad546394b6a3.
--
Antonin Houska
Cybertec Schönig & Schönig G