Re: Parallel Seq Scan vs kernel read ahead

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(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-26 09:09:07
Message-ID: CAApHDvrpLa5NEJp_RpPPnJbGJF90pM7kZizwjbABAqAW1C24Rw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 15 Jul 2020 at 12:24, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> If we've not seen any performance regressions within 1 week, then I
> propose that we (pending final review) push this to allow wider
> testing. It seems we're early enough in the PG14 cycle that there's a
> large window of time for us to do something about any reported
> performance regressions that come in.

I did that final review which ended up in quite a few cosmetic changes.

Functionality-wise, it's basically that of the v2 patch with the
PARALLEL_SEQSCAN_MAX_CHUNK_SIZE set to 8192.

I mentioned that we might want to revisit giving users some influence
on the chunk size, but we'll only do so once we see some conclusive
evidence that it's worthwhile.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2020-07-26 09:36:29 Re: Difference for Binary format vs Text format for client-server communication
Previous Message Michael Paquier 2020-07-26 07:42:06 Re: expose parallel leader in CSV and log_line_prefix