Re: [HACKERS] Small improvement to parallel query docs

On Mon, Feb 13, 2017 at 3:29 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 14 February 2017 at 09:21, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
>> -    table. Each worker will execute the outer side of the plan in full, which
>> -    is why merge joins are not supported here. The outer side of a merge join
>> -    will often involve sorting the entire inner table; even if it involves an
>> -    index, it is unlikely to be productive to have multiple processes each
>> -    conduct a full index scan of the inner table.
>> +    relation. Each worker will execute the inner side of the join in full,
>> +    which is why merge joins are not supported here. The inner side of a merge
>> +    join will often involve sorting the entire inner relation; even if it
>> +    involves an index, it is unlikely to be productive to have multiple
>> +    processes each conduct a full index scan of the inner side of the join.
>>
>> Why s/table/relation/?  I don't think that's useful, especially
>> because the first part of that very same paragraph would still say
>> "table".
>
> Perhaps it's not correct to do that. I did mean relation is the true
> relational theory sense, rather than where relkind = 'r'. I didn't
> really like the way it assumed the inner side was a table. Perhaps its
> better to just say "involve sorting the entire inner side of the join"

Yeah, that seems fine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company