Re: Parallel Seq Scan
От | Jim Nasby |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 54AEDB3F.1000806@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Parallel Seq Scan
Re: Parallel Seq Scan |
Список | pgsql-hackers |
On 1/5/15, 9:21 AM, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> I think it's right to view this in the same way we view work_mem. We >> plan on the assumption that an amount of memory equal to work_mem will >> be available at execution time, without actually reserving it. > > Agreed- this seems like a good approach for how to address this. We > should still be able to end up with plans which use less than the max > possible parallel workers though, as I pointed out somewhere up-thread. > This is also similar to work_mem- we certainly have plans which don't > expect to use all of work_mem and others that expect to use all of it > (per node, of course). I agree, but we should try and warn the user if they set parallel_seqscan_degree close to max_worker_processes, or at leastgive some indication of what's going on. This is something you could end up beating your head on wondering why it'snot working. Perhaps we could have EXPLAIN throw a warning if a plan is likely to get less than parallel_seqscan_degree number of workers. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: