It has been 4 hours and it is safe to say that the measurements we took
have a huge positive effect: > 30 times faster and no noticeable effect on
the running Primary at all.
A 20GB table is now replicated under 10 minutes.
- We removed all non PK and unique indices from the large tables
- We the
Hi,
- on the receiving side, avoid creating indexes on the tables: create just
> a necessary PK or UK, wait for the initial load to complete and then add
> all the rest ones
>
Thanks, this is a good tip. We are going to add this
We also noticed the code that was getting the next from the "queue"
ср, 9 дек. 2020 г. в 10:21, Lars Vonk :
> We are doing a logical postgres replication from Postgres 11 to 12. Our
> database is around 700GB (8 cpu's, 32 GB).
> During the replication process, at some point, we see a huge performance
> penalty on a particular table. This table acts as a queue with
On Wed, Dec 9, 2020 at 2:21 AM Lars Vonk wrote:
> Hi,
>
> We are doing a logical postgres replication from Postgres 11 to 12. Our
> database is around 700GB (8 cpu's, 32 GB).
> During the replication process, at some point, we see a huge performance
> penalty on a particular table. This table act
