Re: First draft of PG 17 release notes

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First draft of PG 17 release notes
Date: 2024-05-15 02:03:32
Message-ID: CAApHDvpog6y=a_WOFt=pEgoq8h5Cx804-ZzCk9MB9oV4vToVKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 15 May 2024 at 13:00, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > "Reduce system calls by automatically merging reads up to io_combine_limit"
>
> Uh, as I understand it, the reduced number of system calls is not the
> value of the feature, but rather the ability to request a larger block
> from the I/O subsystem. Without it, you have to make a request and wait
> for each request to finish. I am open to new wording, but I am not sure
> your new wording is accurate.

I think you have the cause and effect backwards. There's no advantage
to reading 128KB if you only need 8KB. It's the fact that doing
*larger* reads allows *fewer* reads that allows it to be more
efficient. There are also the efficiency gains from fadvise
POSIX_FADV_WILLNEED. I'm unsure how to jam that into a short sentence.
Maybe; "Optimize reading of tables by allowing pages to be prefetched
and read in chunks up to io_combine_limit", or a bit more buzzy;
"Optimize reading of tables by allowing pages to be prefetched and
performing vectored reads in chunks up to io_combine_limit".

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-05-15 02:06:17 Re: First draft of PG 17 release notes
Previous Message Bruce Momjian 2024-05-15 02:02:11 Re: First draft of PG 17 release notes