Re: index prefetching

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: Jim Nasby <jim(dot)nasby(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: index prefetching
Date: 2024-01-17 08:04:43
Message-ID: 67f50c2f-dd82-4c52-ad52-04aa6dbba35c@garret.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 16/01/2024 11:58 pm, Jim Nasby wrote:
> On 1/16/24 2:10 PM, Konstantin Knizhnik wrote:
>> Amazon RDS is just vanilla Postgres with file system mounted on EBS
>> (Amazon  distributed file system).
>> EBS provides good throughput but larger latencies comparing with
>> local SSDs.
>> I am not sure if read-ahead works for EBS.
>
> Actually, EBS only provides a block device - it's definitely not a
> filesystem itself (*EFS* is a filesystem - but it's also significantly
> different than EBS). So as long as readahead is happening somewheer
> above the block device I would expect it to JustWork on EBS.

Thank you for clarification.
Yes, EBS is just block device and read-ahead can be used fir it as for
any other local device.
There is actually recommendation to increase read-ahead for EBS device
to reach better performance on some workloads:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html

So looks like for sequential access pattern manual prefetching at EBS is
not needed.
But at Neon situation is quite different. May be Aurora Postgres is
using some other mechanism for speed-up vacuum and seqscan,
but Neon is using Postgres prefetch mechanism for it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nisha Moond 2024-01-17 08:14:53 Re: Improve the connection failure error messages
Previous Message Michael Paquier 2024-01-17 08:04:36 Re: Fix a typo of func DecodeInsert()