MIME-Version: 1.0
In-Reply-To: <CAGbX52EwdrpPLyRuRRpnbhUqfQYijVz3cShSMuoXrs2Lgkod5Q@mail.gmail.com>
References: <CAGbX52EwdrpPLyRuRRpnbhUqfQYijVz3cShSMuoXrs2Lgkod5Q@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Sun, 16 Jun 2024 00:09:17 -0700
Message-ID: <CAKFQuwbkJ0z8Hz88u3xUtB55nMxzaycFxZAdB1t=BNUBn17YUg@mail.gmail.com>
Subject: Re: Is a VACUUM or ANALYZE necessary after logical replication?
To: Koen De Groote <kdg.dev@gmail.com>
Cc: PostgreSQL General <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000e7cf2d061afc8631"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwbkJ0z8Hz88u3xUtB55nMxzaycFxZAdB1t%3DBNUBn17YUg%40mail.gmail.com>
Precedence: bulk

--000000000000e7cf2d061afc8631
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, June 15, 2024, Koen De Groote <kdg.dev@gmail.com> 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 full=
y
> 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?
>

The whole point of =E2=80=9Clogical=E2=80=9D replication is that the
inserts/updates/deletes are reapplied on the secondary against the table
and the whatever triggers, indexes, or whatnot exist on that table in the
secondary behave just as if you connected to the server directly and issued
the corresponding SQL against it. As far as the replication system is
concerned none of those things on the primary matter nor does it have to
care about them on the secondary.

David J.

--000000000000e7cf2d061afc8631
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, June 15, 2024, Koen De Groote &lt;<a href=3D"mailto:kdg.dev@gm=
ail.com">kdg.dev@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>I&#39;ve gone over all of <a href=3D"https://www.pos=
tgresql.org/docs/current/logical-replication.html" target=3D"_blank">https:=
//www.postgresql.org/<wbr>docs/current/logical-<wbr>replication.html</a> an=
d the only mentions of the word &quot;index&quot; I could find was in relat=
ion to replica identity and examples of table definitions showing primary k=
ey indexes.</div><div><br></div><div>Nothing is said about indexes. Maybe f=
or good reason, maybe they are fully functionality immediately after replic=
ation?</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div=
>The whole point of =E2=80=9Clogical=E2=80=9D replication is that the inser=
ts/updates/deletes are reapplied on the secondary against the table and the=
 whatever triggers, indexes, or whatnot exist on that table in the secondar=
y behave just as if you connected to the server directly and issued the cor=
responding SQL against it. As far as the replication system is concerned no=
ne of those things on the primary matter nor does it have to care about the=
m on the secondary.</div><div><br></div><div>David J.</div><div><br></div>

--000000000000e7cf2d061afc8631--