Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sFV7P-002toF-W9 for pgsql-general@arkaria.postgresql.org; Fri, 07 Jun 2024 08:38:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sFV7N-009vLM-IM for pgsql-general@arkaria.postgresql.org; Fri, 07 Jun 2024 08:38:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sF4w0-00F1Mv-8t for pgsql-general@lists.postgresql.org; Thu, 06 Jun 2024 04:41:08 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sF4vt-003gXI-4i for pgsql-general@lists.postgresql.org; Thu, 06 Jun 2024 04:41:06 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-24c9f91242dso248744fac.2 for ; Wed, 05 Jun 2024 21:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fresho.com; s=google; t=1717648860; x=1718253660; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+KAprBqQ5R1vv/HxNV68a+dMRcysVApnMu5Y8GL0GsU=; b=Q6uwnIBqGmmVFDR1HMYgAkabo+ch5D3sabUN/0ABmaFXsYLRJFqjZY+7lQmxJfKeGp r/+MqF0MUgsMXenA57dAAWTVsqFhofp0JSrW9e/KQtm4Frp6peqiGhp4ylJ2kBqYKXDZ LPdUXP4EUVaj4TZ4fHFOqMGfSThARc4i3vOqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717648860; x=1718253660; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+KAprBqQ5R1vv/HxNV68a+dMRcysVApnMu5Y8GL0GsU=; b=HrEzfn1/lFjb2JC37nmpVkpwj0POawfFUp/0hRQzEd1U2SxouiKUgkJ1pukbbTp7DL S7UxMyPoK9WgujbGBNGaQle5ZH3xbixZJ6tVB3b4ByoMSOa+Z6dHBG3gMJwU+OijSjVu Y7XycksrwiB6/s9jsuJFUL/ebgmBHXtpXt5LttJLxJR4yZmlLlLOFcLrJbRxGUFLK53R X43fPGt/C+IlsPg12sN3uWwpq/vvKGp/lmocIBz5oNg1vt8OfxCalYnr+wKi1tHwJnBu ot+8CPls6lGQDjgRHRuMQgESLzyyQH+NwFuzehnieygdfhksnYUBvVHCYmGqdCq3c+Mu PcXw== X-Gm-Message-State: AOJu0Yy9mO9i2P/dPiiMFsdgYYS1OoNTEOQhPP3PaXyzsC2ramTirBB2 DJwt+BnXouu8Tir22L0K21EjrzAyexprwKB2S1BQkBTNQO4Zi3ZYoHNPZ8DB+sNjiz9TdvozPji ywFgmYDPR69ZzcYBFGOtGuggaiMinZktlodtKZA== X-Google-Smtp-Source: AGHT+IGAVOnDSPxp4mAlANi8568LaRR1bwu2+rX5j+wqeVVjrIP7J1YgDebnqm3T0mMKpzM29LjI4gv0icf8W6a7hQs= X-Received: by 2002:a05:6870:8181:b0:250:725f:ed57 with SMTP id 586e51a60fabf-25121c950fcmr4979768fac.10.1717648860411; Wed, 05 Jun 2024 21:41:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sam Kidman Date: Thu, 6 Jun 2024 14:40:49 +1000 Message-ID: Subject: Re: Poor performance after restoring database from snapshot on AWS RDS To: Jeremy Smith Cc: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > 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) 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=E2=80=AFPM Jeremy Smith wrote: > > On Wed, Jun 5, 2024 at 4:23=E2=80=AFAM Sam Kidman 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/USE= R_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