Re: Parallel Seq Scan vs kernel read ahead - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan vs kernel read ahead
Date
Msg-id CAA4eK1LF7oYNXtdn89EPOiH5ae+TexL5xjZLQ+rSQCSH7JPv9A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan vs kernel read ahead  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Parallel Seq Scan vs kernel read ahead  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers
On Tue, Jul 21, 2020 at 3:08 PM k.jamison@fujitsu.com
<k.jamison@fujitsu.com> wrote:
>
> On Tuesday, July 21, 2020 12:18 PM, Amit Kapila wrote:
> > On Tue, Jul 21, 2020 at 8:06 AM k.jamison@fujitsu.com <k.jamison@fujitsu.com>
> > wrote:
> > >
> > > I am definitely missing something. Perhaps I think I could not
> > > understand why there's no I/O difference between the Master and
> > > Patched (V2). Or has it been already improved even without this patch?
> > >
> >
> > I don't think it is strange that you are not seeing much difference because as per
> > the initial email by Thomas this patch is not supposed to give benefits on all
> > systems.  I think we wanted to check that the patch should not regress
> > performance in cases where it doesn't give benefits.  I think it might be okay to
> > run with a higher number of workers than you have CPUs in the system as we
> > wanted to check if such cases regress as shown by Soumyadeep above [1].  Can
> > you once try with
> > 8 and or 10 workers as well?
> >
>
> You are right. Kindly excuse me on that part, which only means it may or may not have any
> benefits on the filesystem I am using. But for other fs, as we can see from David's benchmarks
> significant results/benefits.
>
> Following your advice on regression test case, I increased the number of workers,
> but the query planner still capped the workers at 6, so the results from 6 workers onwards
> are almost the same.
>

I am slightly confused if the number of workers are capped at 6, then
what exactly the data at 32 worker count means?  If you want query
planner to choose more number of workers, then I think either you need
to increase the data or use Alter Table <tbl_name> Set
(parallel_workers = <num_workers_you_want>);

> I don't see significant difference between master and patched on my machine
> as per my test results below. (Just for reconfirmation)
>

I see the difference of about 7-8% at higher (32) client-count.  Am, I
missing something?

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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel copy
Next
From: Dilip Kumar
Date:
Subject: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING