From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Eden Aharoni <edena(at)legitsecurity(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: RDS IO Read time |
Date: | 2025-03-31 15:15:39 |
Message-ID: | DA3CFE03-C653-41D8-8F85-604A948C71F1@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Mar 31, 2025, at 06:54, Eden Aharoni <edena(at)legitsecurity(dot)com> wrote:
> Is this expected IO read rate? I can’t help but feel we’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. From 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Renan Alves Fonseca | 2025-03-31 16:41:54 | Re: Querying one partition in a function takes locks on all partitions |
Previous Message | Adrian Klaver | 2025-03-31 15:08:00 | Re: RDS IO Read time |