Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE |
Дата | |
Msg-id | CA+TgmoZ5Z7gzOSK+mEe7jMGKBtbdH5XWc5xPampAYWRi7dmSqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE
|
Список | pgsql-hackers |
On Fri, Jun 2, 2017 at 9:01 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > Your reasoning sounds sensible to me. I think the other way to attack > this problem is that we can maintain some local queue in each of the > workers when the shared memory queue becomes full. Basically, we can > extend your "Faster processing at Gather node" patch [1] such that > instead of fixed sized local queue, we can extend it when the shm > queue become full. I think that way we can handle both the problems > (worker won't stall if shm queues are full and workers can do batched > writes in shm queue to avoid the shm queue communication overhead) in > a similar way. We still have to bound the amount of memory that we use for queueing data in some way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: