From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel joins, and better parallel explain |
Date: | 2015-11-26 08:45:53 |
Message-ID: | CANP8+jLPb+Cd21qe3UL0=JrxAyb7MA18qgbtv7DEx5-uLy-jLw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 November 2015 at 03:41, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Attached find a patch that does (mostly) two things. First, it allows
> the optimizer to generate plans where a Nested Loop or Hash Join
> appears below a Gather node. This is a big improvement on what we
> have today, where only a sequential scan can be parallelized; with
> this patch, entire join problems can be parallelized, as long as they
> don't need a Merge Join (see below for more on this).
Sounds like good progress.
This gives us multiple copies of the hash table, which means we must either
use N * work_mem, or we must limit the hash table to work_mem / N per
partial plan.
How can the partial paths share a hash table?
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2015-11-26 09:00:54 | Re: Optimization for updating foreign tables in Postgres FDW |
Previous Message | Michael Paquier | 2015-11-26 07:17:27 | Re: pg_stat_replication log positions vs base backups |