Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Дата | |
| Msg-id | CA+TgmoYQxnRujTSLbB4vMn_2_Mizh9C0UqghfAKqZ0bc0H6sWw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
|
| Список | pgsql-hackers |
On Wed, Jan 10, 2018 at 5:42 PM, Peter Geoghegan <pg@bowt.ie> wrote: > On Wed, Jan 10, 2018 at 2:21 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> I share your general feelings on all of this, but I really don't know >>> what to do about it. Which of these alternatives is the least worst, >>> all things considered? >> >> Let's get the patch committed without any explicit way of forcing the >> number of workers and then think about adding that later. > > It could be argued that you need some way of forcing low memory in > workers with any committed version. So while this sounds reasonable, > it might not be compatible with throwing out what I've done with > force_parallel_mode up-front, before you commit anything. What do you > think? I think the force_parallel_mode thing is too ugly to live. I'm not sure that forcing low memory in workers is a thing we need to have, but if we do, then we'll have to invent some other way to have it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: