Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: RDS IO Read time
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <DBBPR03MB102227BDDC40A11527BF6C0C0BBAD2@DBBPR03MB10222.eurprd03.prod.outlook.com>
Date: Mon, 31 Mar 2025 08:15:39 -0700
Cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA3CFE03-C653-41D8-8F85-604A948C71F1@thebuild.com>
References: <DBBPR03MB102227BDDC40A11527BF6C0C0BBAD2@DBBPR03MB10222.eurprd03.prod.outlook.com>
To: Eden Aharoni <edena@legitsecurity.com>
Archived-At: <https://www.postgresql.org/message-id/DA3CFE03-C653-41D8-8F85-604A948C71F1%40thebuild.com>
Precedence: bulk


> On Mar 31, 2025, at 06:54, Eden Aharoni <edena@legitsecurity.com> =
wrote:
> Is this expected IO read rate? I can=E2=80=99t help but feel we=E2=80=99=
re missing something here..

Really, no particular I/O rate is "expected": if PostgreSQL needs that =
much data, it'll use that much I/O to get it.  =46rom your description, =
it's likely that it's a case of the working set for the database just =
not fitting into the memory you have, so PostgreSQL needs to go out to =
secondary storage a lot to fetch the data.

The best first step is to use Performance Insights to see which queries =
are using I/O, and run sample ones with EXPLAIN (ANALYZE, BUFFERS) to =
see where the I/O is being used within the query.  Given that you allow =
users to assemble arbitrary queries, it's likely that PostgreSQL is =
having to use a wide variety of indexes (or sequential scans), so it =
can't successfully cache a particular set in memory.=