Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1KFFvcsDu3uYyDK-Vgzugfo5az0B35W6uxAi+Fvg8UaDg@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel Seq Scan  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Re: Parallel Seq Scan  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List 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 by date:

Previous
From: "Thakur, Sameer"
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Egor Rogov
Date:
Subject: REVOKE [ADMIN OPTION FOR] ROLE