Re: Parallel Seq Scan vs kernel read ahead

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Seq Scan vs kernel read ahead
Date: 2020-07-21 10:32:30
Message-ID: CAA4eK1LF7oYNXtdn89EPOiH5ae+TexL5xjZLQ+rSQCSH7JPv9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 21, 2020 at 3:08 PM k(dot)jamison(at)fujitsu(dot)com
<k(dot)jamison(at)fujitsu(dot)com> wrote:
>
> On Tuesday, July 21, 2020 12:18 PM, Amit Kapila wrote:
> > On Tue, Jul 21, 2020 at 8:06 AM k(dot)jamison(at)fujitsu(dot)com <k(dot)jamison(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-07-21 10:38:36 Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Previous Message Amit Kapila 2020-07-21 10:24:14 Re: Parallel copy