Re: PgSQL 14 - Logical Rep - Single table multiple publications?

From: Robert Blayzor <rblayzor(dot)bulk(at)inoc(dot)net>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: PgSQL 14 - Logical Rep - Single table multiple publications?
Date: 2022-08-02 16:09:58
Message-ID: 8bd0f6cd-cbfc-2033-431c-d4ac613c1878@inoc.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 8/2/22 10:57, Rory Campbell-Lange wrote:
> Special care must be taken with the "replica identity" of published
> tables, as set out at
> https://www.postgresql.org/docs/current/logical-replication-publication.html.
> For example, you may need a unique identifying column for each source
> table in addition to the normal row identifier to differentiate*this*
> table's id 1 row from the*other* table's id 1 row, otherwise the
> subscriber won't be able to identify the row to delete if this table's
> id 1 row is deleted (for example).
>
> Although this seems to work fine with native replication, the pglogical
> extension has more knobs. For instance, the
> pglogical.wait_for_subscription_sync_complete function is useful to ensure that
> sync finishes when part of a migration.

We would literally just be merging bulk data rows that are considered
immutable, meaning they would never be updated or deleted. We would
replicate only inserts, not deletes, updates, etc.

Would the table identifier still be required in this case?

We have a half a dozen DB's that just collect call records, they are in
different locations. They get their local call data and store it into
their local table. We would want to aggregate all that data in a central
subscription database table for pure analytics/reporting purposes...

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP: https://pgp.inoc.net/rblayzor/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message bruno da silva 2022-08-02 17:02:41 Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
Previous Message Tom Lane 2022-08-02 15:59:21 Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries