| From: | Jeremy Smith <jeremy(at)musicsmith(dot)net> |
|---|---|
| To: | Sam Kidman <sam(at)fresho(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Poor performance after restoring database from snapshot on AWS RDS |
| Date: | 2024-06-05 12:09:34 |
| Message-ID: | CAM8SmLUMREu3MOSpfh58EoV9ysgWi8sFkbj_BnBJQjeJn3C+7Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Jun 5, 2024 at 4:23 AM Sam Kidman <sam(at)fresho(dot)com> wrote:
> We get very poor performance in the staging environment after this
> restore takes place - after some usage it seems to get better perhaps
> because of caching.
>
This is due to the way that RDS restores snapshots.
From the docs (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html)
You can use the restored DB instance as soon as its status is
available. The DB instance continues to load data in the background.
This is known as lazy loading.
If you access data that hasn't been loaded yet, the DB instance
immediately downloads the requested data from Amazon S3, and then
continues loading the rest of the data in the background.
-Jeremy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Roy | 2024-06-05 14:22:35 | Re: Purpose of pg_dump tar archive format? |
| Previous Message | Laurenz Albe | 2024-06-05 10:26:03 | Re: Logical replication type- WAL recovery fails and changes the size of wal segment in archivedir |