On Fri, Jun 7, 2024 at 4:36 AM Sam Kidman <s...@fresho.com> wrote: > > This is due to the way that RDS restores snapshots. > > Thanks, I never would have guessed. Would vacuum analyze be sufficient > to defeat the lazy loading or would we need to do something more > specific to our application? (for example. select(*) on some commonly > used tables) >
https://www.postgresql.org/docs/14/pgprewarm.html pg_prewarm is probably what you want. Don't know if RDS Postgresql supports it or not, though. > > I think vacuum full would certainly defeat the lazy loading since it > would copy all of the table data, but that may take a very long time > to run. I think vacuum analyze only scans a subset of rows but I might > be wrong about that. > > Best, Sam > > On Wed, Jun 5, 2024 at 10:09 PM Jeremy Smith <jer...@musicsmith.net> > wrote: > > > > On Wed, Jun 5, 2024 at 4:23 AM Sam Kidman <s...@fresho.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 > > >
