On Mon, Feb 13, 2017 at 3:29 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 14 February 2017 at 09:21, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
