evaluating target list in parallel workers
| От | Robert Haas |
|---|---|
| Тема | evaluating target list in parallel workers |
| Дата | |
| Msg-id | CA+TgmoaqWH8W35c7pssuufxOO=AxNEQEN4da_BkeQaA3SE33QQ@mail.gmail.com обсуждение исходный текст |
| Список | pgsql-hackers |
On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Um ... why would you not want the projections to happen in the child >> nodes, where they could be parallelized? Or am I missing something? > > You probably would, but sometimes that might not be possible; for > example, the tlist might contain a parallel-restricted function (which > therefore has to run in the leader). And here's a (rather small) patch to push target-list evaluation down to the worker whenever possible. With this, if you do something like ... SELECT aid + bid FROM pgbench_accounts WHERE aid % 10000 = 0; ...then aid + bid can be calculated in the workers rather than in the leader. Unfortunately, if you do this... SELECT sum(aid + bid) FROM pgbench_accounts WHERE aid % 10000 = 0; ...then it doesn't help, because make_subplanTargetList() thinks it may as well just pull aid and bid out of the join nest and then do the sum during the aggregation stage. Presumably if we get the parallel aggregation stuff working then this will get fixed, because there will be a Partial Aggregate step before the Gather. But whether that gets into 9.6 or not, this seems like a useful step forward. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: