diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index e68902ae34..3cde6d37fa 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -4623,9 +4623,11 @@ ApplyWorkerMain(Datum main_arg)
 	if (!am_tablesync_worker())
 	{
 		/*
-		 * Time-delayed logical replication does not support tablesync
-		 * workers, so only the leader apply worker can request walsenders to
-		 * delay on the publisher side.
+		 * We support time-delayed logical replication only for the apply
+		 * worker. This is because if we support delay during the initial sync
+		 * then once we reach the limit of tablesync workers it would impose a
+		 * delay for each subsequent worker. That would cause initial table
+		 * synchronization completion to take a long time.
 		 */
 		if (server_version >= 160000 && MySubscription->minsenddelay > 0)
 			options.proto.logical.min_send_delay = MySubscription->minsenddelay;
diff --git a/src/backend/replication/pgoutput/pgoutput.c b/src/backend/replication/pgoutput/pgoutput.c
index 61faf2d685..90bbea941b 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replication/pgoutput/pgoutput.c
@@ -529,7 +529,10 @@ pgoutput_startup(LogicalDecodingContext *ctx, OutputPluginOptions *opt,
 		else
 			ctx->twophase_opt_given = true;
 
-		/* Copy given time period to decoding context */
+		/*
+		 * Remember the delay time period to be used later before sending the
+		 * changes.
+		 */
 		ctx->min_send_delay = data->min_send_delay;
 
 		/* Init publication state. */
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 9f3968928f..ad3515821e 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -3854,13 +3854,15 @@ LagTrackerRead(int head, XLogRecPtr lsn, TimestampTz now)
 /*
  * LogicalDecodingContext 'delay' callback.
  *
- * Wait long enough to make sure a transaction is applied at least that
- * period behind the publisher.
+ * Wait long enough to make sure a transaction is applied at least
+ * min_send_delay time period after it is performed at the publisher.
+ *
+ * delay_start is the transaction end time.
  */
 static void
 WalSndDelay(LogicalDecodingContext *ctx, TransactionId xid, TimestampTz delay_start)
 {
-	/* Wait till delayUntil by the latch mechanism */
+	/* Apply the delay by the latch mechanism */
 	while (true)
 	{
 		TimestampTz now;
diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl
index ad0831bb1a..a273e7df68 100644
--- a/src/test/subscription/t/001_rep_changes.pl
+++ b/src/test/subscription/t/001_rep_changes.pl
@@ -518,10 +518,10 @@ $node_publisher->poll_query_until('postgres',
 # Test time-delayed logical replication
 #
 # If the subscription sets min_send_delay parameter, the walsender will delay
-# the transaction send for min_send_delay milliseconds. We verify this by
-# looking at the time difference between a) when tuples are inserted on the
-# publisher, and b) when those changes are replicated on the subscriber. Even
-# on slow machines, this strategy will give predictable behavior.
+# the transaction for min_send_delay milliseconds. We verify this by looking
+# at the time difference between a) when tuples are inserted on the publisher,
+# and b) when those changes are replicated on the subscriber. Even on slow
+# machines, this strategy will give predictable behavior.
 
 # Set min_send_delay parameter to 3 seconds
 my $delay = 3;