Subject: Is a VACUUM or ANALYZE necessary after logical replication?

From: Koen De Groote <[email-masked]>
Date: Sun, 16 Jun 2024 00:55:50 +0200

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

---

From: Adrian Klaver <[email-masked]>
Date: Sat, 15 Jun 2024 16:13:32 -0700

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 
> <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?
> 

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.

-- 
Adrian Klaver
[email-masked]

---

From: Achilleas Mantzios <[email-masked]>
Date: Sun, 16 Jun 2024 09:54:58 +0300

Στις 16/6/24 02:13, ο/η Adrian Klaver έγραψε:
>> <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.
>>

Hi Adrian, however in case the replication is problematic due to e.g. :

- wrong encoding to the new system, e.g. from SQL_ASCII to UTF-8

- ALWAYS triggers written without full schema qualification or other 
problems throwing ERRORs, etc

- server restarts during the sync phase

- etc

those will produce rollbacks, hence bloating right from the start. In 
those cases either VACUUM FULL will be needed, or even better correct 
the errors in their source and repeat the whole process. Normally the 
new DB (subscriber) should be a little smaller than the original 
(publisher).

As you said, in any case, ANALYZE will be always needed afterwards, as 
well as taking care of sequences. IMHO the sequence part would be nice 
to be handled in a more elegant manner, e.g. by an option in pg_dump to 
dump only sequences, for "nearly zero" downtime upgrades, this step 
should happen rapidly at the switchover.

-- 
Achilleas Mantzios
  IT DEV - HEAD
  IT DEPT
  Dynacom Tankers Mgmt (as agents only)

---

From: "David G. Johnston" <[email-masked]>
Date: Sun, 16 Jun 2024 00:09:17 -0700

On Saturday, June 15, 2024, Koen De Groote <[email-masked]> 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

The whole point of “logical” 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.