public inbox for [email protected]
help / color / mirror / Atom feedLogical replication initialization time depends dramatically on the publication "schema" size
2+ messages / 2 participants
[nested] [flat]
* Logical replication initialization time depends dramatically on the publication "schema" size
@ 2026-06-05 10:11 Crimean (gmail) <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Crimean (gmail) @ 2026-06-05 10:11 UTC (permalink / raw)
To: [email protected]
Hello,
I would like to report a scalability issue I observed during logical
replication initialization.
The problem is not that replication fails or behaves incorrectly. However,
initialization time appears to increase significantly as the number of
tables in a publication grows.
While investigating, I noticed the following query being executed:
SELECT DISTINCT
(CASE WHEN (array_length(gpt.attrs, 1) = c.relnatts)
THEN NULL
ELSE gpt.attrs
END)
FROM pg_publication p,
LATERAL pg_get_publication_tables(p.pubname) gpt,
pg_class c
WHERE gpt.relid = 236073
AND c.oid = gpt.relid
AND p.pubname IN ('p1');
According to AWS Performance Insights, this query shows an average latency
of more than 130 ms and approximately 113,799 buffer hits per execution
when the publication contains around 10,000 tables.
As a result, the subscription initialization rate degrades from roughly 28
tables/second with 500 tables in the publication to about 8 tables/second
with 10,000 tables.
In my environment, replication itself works correctly, but initialization
time increases substantially as publication size grows. Unfortunately, some
of my deployments contain very large schemas, with over 1 million tables on
the publisher side, making this behavior a practical problem.
I can provide PostgreSQL version information, execution plans, and
reproduction details if needed.
Thank you for your time.
Best regards,
Sergii
^ permalink raw reply [nested|flat] 2+ messages in thread
* RE: Logical replication initialization time depends dramatically on the publication "schema" size
@ 2026-06-08 12:31 Hayato Kuroda (Fujitsu) <[email protected]>
parent: Crimean (gmail) <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2026-06-08 12:31 UTC (permalink / raw)
To: 'Crimean (gmail)' <[email protected]>; +Cc: [email protected] <[email protected]>
Dear Crimean,
Thanks for the report. I think the issue has solved by the commit fd7a25a [1],
which is available in upcoming PG19.
Could you please try to test the beta version on your env if possible?
Sadly, we cannot backport the commit to older versions because it must change
the catalog version.
[1]: https://github.com/postgres/postgres/commit/fd7a25af11e2cad4f48ffc4e50f18644e657ed53
Best regards,
Hayato Kuroda
FUJITSU LIMITED
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-06-08 12:31 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-05 10:11 Logical replication initialization time depends dramatically on the publication "schema" size Crimean (gmail) <[email protected]>
2026-06-08 12:31 ` Hayato Kuroda (Fujitsu) <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox