Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA4eK1KFFvcsDu3uYyDK-Vgzugfo5az0B35W6uxAi+Fvg8UaDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Re: Parallel Seq Scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
On Wed, Jul 22, 2015 at 9:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> One thing I noticed that is a bit dismaying is that we don't get a lot
> of benefit from having more workers.  Look at the 0.1 data.  At 2
> workers, if we scaled perfectly, we would be 3x faster (since the
> master can do work too), but we are actually 2.4x faster.  Each
> process is on the average 80% efficient.  That's respectable.  At 4
> workers, we would be 5x faster with perfect scaling; here we are 3.5x
> faster.   So the third and fourth worker were about 50% efficient.
> Hmm, not as good.  But then going up to 8 workers bought us basically
> nothing.
>

I think the improvement also depends on how costly is the qualification,
if it is costly, even for same selectivity the gains will be shown till higher
number of clients and for simple qualifications, we will see that cost of
having more workers will start dominating (processing data over multiple
tuple queues) over the benefit we can achieve by them.


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

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

Предыдущее
От: "Thakur, Sameer"
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.
Следующее
От: Egor Rogov
Дата:
Сообщение: REVOKE [ADMIN OPTION FOR] ROLE