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 1sIcJj-00GrAQ-0J for pgsql-general@arkaria.postgresql.org; Sat, 15 Jun 2024 22:56:15 +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 1sIcJg-000UKB-DE for pgsql-general@arkaria.postgresql.org; Sat, 15 Jun 2024 22:56:13 +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 1sIcJf-000UK3-Vs for pgsql-general@lists.postgresql.org; Sat, 15 Jun 2024 22:56:12 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sIcJZ-001VK3-Of for pgsql-general@lists.postgresql.org; Sat, 15 Jun 2024 22:56:11 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ec002caf3eso54787851fa.1 for ; Sat, 15 Jun 2024 15:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718492163; x=1719096963; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pAXW7zGjDWnMUH4UKOTzLsVTzbsifINCEXRRsQUjcqE=; b=kURWI1Ou/n6vXNmiKpHid6f+YUHlDEBCp0ISf8bDyS+/eqYkqnxv+It1xWHUsG4ntO UieKe8dmJfPbclEDTf97aHvpp7adpRRWOZ/cWKKzCCJkK3v9EY5gpp5YOidesoRSlC6H as1VRyy0aNanl64P9pASv46tthvmOPboK0PTivoX5yJvi01jRnGSXlUSfMl7HBl2/J1p kMP66tRpECzOZTZY1hAornBEvPMjpvsZUW6LbU3QbVjzzUMImrQuEt75e7+MiyzQfsjY 3nBVWDDCtuAZiLtmi+SF7kAIhA5WG9feavHcoikqaO26xyvHSdk5aSjJS0heedHI4zs1 B1rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718492163; x=1719096963; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pAXW7zGjDWnMUH4UKOTzLsVTzbsifINCEXRRsQUjcqE=; b=MOJXY32lI/z+jBwLueF6E9NlwSC/sivGGhmdjPuBxUtgZnnTDrQi1vEGCc9tDj10iR d0NfjQ8C5E+wOTK3RwzP6qjMRREeeFXG0ULvjdWbZVQzqTKcROGy3290ewkbb374+f4v OZIqeG26I4SmgtJX3pDuKMsgdFTSAeI6IzmsJ3mXZfncc5Zoj/9cIJ6rDu3YyS+jrrPT ilP3L/nqDEPoXJkDiVFPM1UFz866bD3KFvjFzaLbeO5o0aLR6ewgZkMjXJ1Eorg6YEYZ 4Aqhf++AvD4qTcfSKQIk9e/NZX+VYK7dnnohDCuIWbocOsebhT52tbt4VI/paIRyhAVX UQAQ== X-Gm-Message-State: AOJu0YxY9NWls72k81l2Jc5NUaY6Rsbic6nMX4F6zmrNGQfdJQ9zAB/9 cUJN40iMEqXmRMHy1zf6k9V8rnXTtKzr0+rJF4Jqo0rB4MomuVyrEfSjnvXIkJcU13tnnp7iqtU Ff4BB8Td2rpEJP5pUrcpOkg/aoETZarID X-Google-Smtp-Source: AGHT+IGQhLzyuZDnn4EJStD01NIIrM9hhAGmrm3/dLESC8dYsPJGVrqBxB8QGWW8Va6SuoM8uPteg1DfWBevyd0SsTk= X-Received: by 2002:ac2:5de8:0:b0:52c:8289:e891 with SMTP id 2adb3069b0e04-52ca6e56efamr4678192e87.6.1718492162318; Sat, 15 Jun 2024 15:56:02 -0700 (PDT) MIME-Version: 1.0 From: Koen De Groote Date: Sun, 16 Jun 2024 00:55:50 +0200 Message-ID: Subject: Is a VACUUM or ANALYZE necessary after logical replication? To: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000e26ab8061af5a2ba" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e26ab8061af5a2ba Content-Type: text/plain; charset="UTF-8" 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? Regards, Koen De Groote --000000000000e26ab8061af5a2ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've gone over all of https://www.postgresql.or= g/docs/current/logical-replication.html and the only mentions of the wo= rd "index" I could find was in relation to replica identity and e= xamples of table definitions showing primary key indexes.

Nothing is said about indexes. Maybe for good reason, maybe they ar= e fully functionality immediately after replication?

So the main question: Once a table is fully replicated, do I need to vac= uum(analyze) that table, or are the indexes on that table already functiona= l?

Regards,
Koen De Groote
--000000000000e26ab8061af5a2ba--