From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small improvement to parallel query docs |
Date: | 2017-02-13 20:29:33 |
Message-ID: | CAKJS1f8Cy-5U0jSvsU5VQ7FsdwtA--VSEN+OjYFcDTzCmc_02Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14 February 2017 at 09:21, Robert Haas <robertmhaas(at)gmail(dot)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"
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-13 20:31:01 | Re: Small improvement to parallel query docs |
Previous Message | Robert Haas | 2017-02-13 20:21:22 | Re: Small improvement to parallel query docs |