public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dimitrios Apostolou <[email protected]>
To: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: Performance implications of 8K pread()s
Date: Fri, 12 Apr 2024 13:12:55 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGLisdw=PLn-cjtnUh7QQ_6o85vSH8bk_FjKwyEgqd2mPw@mail.gmail.com>
References: <[email protected]>
	<CA+hUKGLisdw=PLn-cjtnUh7QQ_6o85vSH8bk_FjKwyEgqd2mPw@mail.gmail.com>

Exciting! Since I still have the same performance issues on compressed btrfs, I'm looking forward to testing the patches, probably when a 17 Beta is out and I can find binaries on my platform (OpenSUSE). It looks like it will make a huge difference.

Thank you for persisting and getting this through.

Dimitris


On 12 April 2024 07:45:52 CEST, Thomas Munro <[email protected]> wrote:
>On Wed, Jul 12, 2023 at 1:11 AM Dimitrios Apostolou <[email protected]> wrote:
>> So would it make sense for postgres to perform reads in bigger blocks? Is it
>> easy-ish to implement (where would one look for that)? Or must the I/O unit be
>> tied to postgres' page size?
>
>FYI as of last week we can do a little bit of that on the master branch:
>
>postgres=# select count(*) from t;
>
>preadv(46, ..., 8, 256237568) = 131072
>preadv(46, ..., 5, 256368640) = 131072
>preadv(46, ..., 8, 256499712) = 131072
>preadv(46, ..., 5, 256630784) = 131072
>
>postgres=# set io_combine_limit = '256k';
>postgres=# select count(*) from t;
>
>preadv(47, ..., 5, 613728256) = 262144
>preadv(47, ..., 5, 613990400) = 262144
>preadv(47, ..., 5, 614252544) = 262144
>preadv(47, ..., 5, 614514688) = 262144
>
>Here's hoping the commits implementing this stick, for the PostgreSQL
>17 release.  It's just the beginning though, we can only do this for
>full table scans so far (plus a couple of other obscure places).
>Hopefully in the coming year we'll get the "streaming I/O" mechanism
>that powers this hooked up to lots more places... index scans and
>other stuff.  And writing.  Then eventually pushing the I/O into the
>background.  Your questions actually triggered us to talk about why we
>couldn't switch a few things around in our project and get the I/O
>combining piece done sooner.  Thanks!

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Performance implications of 8K pread()s
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox