| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | James Sewell <james(dot)sewell(at)lisasoft(dot)com> |
| Cc: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
| Subject: | Re: Choosing parallel_degree |
| Date: | 2016-03-20 10:23:48 |
| Message-ID: | CAKJS1f_st=BtRjv=_=7k2O8CsKJEp0OzEftyYWK5R21E0fWXFw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18 March 2016 at 10:13, James Sewell <james(dot)sewell(at)lisasoft(dot)com> wrote:
> This does bring up an interesting point I don't quite understand though. If I run parallel agg on a table with 4 rows with 2 workers will it run on two workers (2 rows each) or will the first one grab all 4 rows?
It works on a per page basis, workers just each grab the next page to
be scanned from a page counter that sits in shared memory, the worker
just increments the page number, releases the lock on the counter and
scans that page.
See heap_parallelscan_nextpage()
So the answer to your question is probably no. At least not unless the
the page only contained 2 rows.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2016-03-20 12:31:30 | Re: Performance degradation in commit ac1d794 |
| Previous Message | David Rowley | 2016-03-20 08:58:08 | Re: Parallel Aggregate |