| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Subject: | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Date: | 2018-01-11 20:25:26 |
| Message-ID: | CAH2-WzmhArdpM7nDN+P4E=97LwfS-C8Coi+ZZUmyYCYny9B77g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 11, 2018 at 12:06 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> It might make sense to have the "minimum memory per participant" value
> come from a GUC, rather than be hard coded (it's currently hard-coded
> to 32MB).
> What do you think of that idea?
A third option here is to specifically recognize that
compute_parallel_worker() returned a value based on the table storage
param max_workers, and for that reason alone no "insufficient memory
per participant" decrementing/vetoing should take place. That is, when
the max_workers param is set, perhaps it should be completely
impossible for CREATE INDEX to ignore it for any reason other than an
inability to launch parallel workers (though that could be due to the
max_parallel_workers GUC's setting).
You could argue that we should do this anyway, I suppose.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2018-01-11 20:32:50 | Re: IndexTupleDSize macro seems redundant |
| Previous Message | Peter Geoghegan | 2018-01-11 20:06:31 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |