RE: Initial COPY of Logical Replication is too slow - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Initial COPY of Logical Replication is too slow
Date
Msg-id OS9PR01MB1214993716A59D343ADB9C039F552A@OS9PR01MB12149.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Initial COPY of Logical Replication is too slow  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Initial COPY of Logical Replication is too slow
List pgsql-hackers
Dear Sawada-san,

Thanks for updating the patch. I think the patch has a good shape.
Below contains minor comments.


```
+               if (filter_by_relid)
+                       relkind = get_rel_relkind(target_relid);
```

Can we return here if the relkind is not RELKIND_RELATION nor RELKIND_PARTITIONED_TABLE?
Key assumption here is that pg_get_publication_tables_b() returns at most one
tuple, thus this is would be called only once.

```
+       /*
+        * Non-alltables
+        */
+       if (relispartition)
```

else-if might be usalbe to clarify we're in the non-alltables case.

```
+               Assert(pubnames != NULL);
```

Personally I prefer to do Assert() before the SRF_FIRSTCALL_INIT(). Because it's
only related with argument and not related with other function calls.

```
+  proname => 'pg_get_publication_tables', prorows => '10',
```

Can prorows be 1? Because only a row would be returned here.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: "Anton A. Melnikov"
Date:
Subject: .bc files build dependency issues.
Next
From: Jim Jones
Date:
Subject: Re: Add max_wal_replay_size connection parameter to libpq