Re: [HACKERS] [POC] Faster processing at Gather node

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] [POC] Faster processing at Gather node
Дата
Msg-id CAA4eK1+yDV_8MzSOPN2nSFU5Dk6dWn+Zs3bVbR3TOa3jtQU_Ww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [POC] Faster processing at Gather node  (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>)
Ответы Re: [HACKERS] [POC] Faster processing at Gather node  (Rafia Sabih <rafia.sabih@enterprisedb.com>)
Список pgsql-hackers
On Fri, Sep 8, 2017 at 11:07 PM, Alexander Kuzmenkov
<a.kuzmenkov@postgrespro.ru> wrote:
> Hi Rafia,
>
> I like the idea of reducing locking overhead by sending tuples in bulk. The
> implementation could probably be simpler: you could extend the API of shm_mq
> to decouple notifying the sender from actually putting data into the queue
> (i.e., make shm_mq_notify_receiver public and make a variant of shm_mq_sendv
> that doesn't send the notification).
>

Rafia can comment on details, but I would like to bring it to your
notice that we need kind of local buffer (queue) for gathermerge
processing as well where the data needs to be fetched in order from
queues.  So, there is always a chance that some of the workers have
filled their queues while waiting for the master to extract the data.
I think the patch posted by Rafia on the nearby thread [1] addresses
both the problems by one patch.


[1] - https://www.postgresql.org/message-id/CAOGQiiNiMhq5Pg3LiYxjfi2B9eAQ_q5YjS%3DfHiBJmbSOF74aBQ%40mail.gmail.com

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: [HACKERS] Still another race condition in recovery TAP tests
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] new function for tsquery creartion