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 1sIcag-00GsyX-LN for pgsql-general@arkaria.postgresql.org; Sat, 15 Jun 2024 23:13:47 +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 1sIcae-000fgI-DU for pgsql-general@arkaria.postgresql.org; Sat, 15 Jun 2024 23:13:45 +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 1sIcad-000fcR-1F for pgsql-general@lists.postgresql.org; Sat, 15 Jun 2024 23:13:44 +0000 Received: from wfhigh8-smtp.messagingengine.com ([64.147.123.159]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sIcaW-001VQ7-Gh for pgsql-general@lists.postgresql.org; Sat, 15 Jun 2024 23:13:42 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id 7307418000BA; Sat, 15 Jun 2024 19:13:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 15 Jun 2024 19:13:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1718493214; x=1718579614; bh=NXOn/X+geXNUaVcknlbiIZzLweNNB2M02+aQGSUT9OM=; b= OqUxEOiWV4jQ8MgfcCp5gjVBRoOW5HTVVX/nmAIKbBbo4u/trJM5ja5wLn9xibOl eKDU9Kig2pFadMEQunDBCOlHhBRT918TKJN9V8QOQpBN+rFMh0+ZvIbA7alYnusL dWG0Ge6mdrj1XnYUJzQ/VXOtLo3CkNtUBfkD40tNW6loD5GIBvRV2P8dvwHQvotN kRsvP0pQZp9ybofSmgtxrnpv5BB5p1Lq1tGjiSA9+JmYo/p0Bio9eMicbxU0Wttc wONgEsz3tE/XWtRW86NG3yaARUUAASWSMerwKhfRuLwMZSB1x7gb1x5tPp9ZYkR+ y9U/trwh70C3N+qJMqfnYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718493214; x= 1718579614; bh=NXOn/X+geXNUaVcknlbiIZzLweNNB2M02+aQGSUT9OM=; b=P Ycp43sYoQN69OPXEGZonSFZ2a9ApMRQtajoG6XhYvdOZpborkblsuJz1n4FHnvYz Thl5oAXJLd+pPPsySDgvfhWZu3Qaf1GBUiN+lAUmh4YMzMoCeKH6yJfCUG6EP/BF oEXoj8giESvDlykzk4VwV6b14dE1MT7aOpYJdPDnMMOhY+2Gl6GVzYwJSPDyf0Zx cD9343fa1+DJv4hNgS4AVfMRtwir7YHXQqGvvtayQtX7k23kIF9D9XUprAbFH5qW ALRzAG2XGoHej0vQuLbiMJEGuObzVzO0fhLRoRSSZhFxV09zHPK1lN3koP+dtVRk QQoutlsRFbWrY2WS8gH6w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvvddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttddvjeenucfhrhhomheptegurhhi rghnucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtoh hmqeenucggtffrrghtthgvrhhnpeekfeehuddvjeeigfeifeejtdduudffledvfeelheef tdeiffeugfdvkeelgedtvdenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhi rghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Jun 2024 19:13:33 -0400 (EDT) Message-ID: Date: Sat, 15 Jun 2024 16:13:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Is a VACUUM or ANALYZE necessary after logical replication? To: Koen De Groote , PostgreSQL General References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/15/24 15:55, Koen De Groote wrote: > I've gone over all of > https://www.postgresql.org/docs/current/logical-replication.html > and > the only mentions of the word "index" I could find was in relation to > replica identity and examples of table definitions showing primary key > indexes. > > Nothing is said about indexes. Maybe for good reason, maybe they are > fully functionality immediately after replication? > > So the main question: Once a table is fully replicated, do I need to > vacuum(analyze) that table, or are the indexes on that table already > functional? VACUUM/ANALYZE is not about making the index functional. The VACUUM marks the space dead tuples occupy in the table and associated indexes as available for recycling. The ANALYZE updates tables statistics to help the planner make decisions on what query plan to use. On a fresh table VACUUM will not be of much value, ANALYZE though will help by creating up to date table statistics. > > Regards, > Koen De Groote -- Adrian Klaver adrian.klaver@aklaver.com