Re: [HACKERS] [POC] Faster processing at Gather node
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [POC] Faster processing at Gather node |
Дата | |
Msg-id | CA+Tgmoa2gtdwz1ym9DjJu2gO9kdrzhw3XPwP6-jh2c=yXBPYgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] [POC] Faster processing at Gather node (Rafia Sabih <rafia.sabih@enterprisedb.com>) |
Ответы |
Re: [HACKERS] [POC] Faster processing at Gather node
|
Список | pgsql-hackers |
On Fri, May 19, 2017 at 7:55 AM, Rafia Sabih <rafia.sabih@enterprisedb.com> wrote: > While analysing the performance of TPC-H queries for the newly developed > parallel-operators, viz, parallel index, bitmap heap scan, etc. we noticed > that the time taken by gather node is significant. On investigation, as per > the current method it copies each tuple to the shared queue and notifies the > receiver. Since, this copying is done in shared queue, a lot of locking and > latching overhead is there. > > So, in this POC patch I tried to copy all the tuples in a local queue thus > avoiding all the locks and latches. Once, the local queue is filled as per > it's capacity, tuples are transferred to the shared queue. Once, all the > tuples are transferred the receiver is sent the notification about the same. What if, instead of doing this, we switched the shm_mq stuff to use atomics? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: