Re: Parallel Seq Scan vs kernel read ahead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(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-06-22 14:20:02
Message-ID: CA+TgmoZ6C0189RgVHdtsomLa8h5ru0AwAWiQaqwPw=x56qX5iQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 21, 2020 at 6:52 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> Perhaps that's not a problem though, but then again, perhaps just
> keeping it at 131072 regardless of RELSEG_SIZE and BLCKSZ is also ok.
> The benchmarks I did on Windows [1] showed that the returns diminished
> once we started making the step size some decent amount so my thoughts
> are that I've set PARALLEL_SEQSCAN_MAX_CHUNK_SIZE to something large
> enough that it'll make no difference to the performance anyway. So
> there's probably not much point in giving it too much thought.
>
> Perhaps pg_nextpower2_32(RELSEG_SIZE) would be okay though.

I guess I don't care that much; it was just a thought. Maybe tying it
to RELSEG_SIZE is a bad idea anyway. After all, what if we find cases
where 1GB is too much? Like, how much benefit do we get from making it
1GB rather than 64MB, say? I don't think we should be making this
value big just because we can.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-06-22 14:27:18 Update InsertPgAttributeTuple comment to match new signature
Previous Message Tomas Vondra 2020-06-22 14:19:00 Re: [PATCH] Initial progress reporting for COPY command