If I publish a pgbench workload and subscribe to it, the subscription worker is signalling the wal writer thousands of times a second, once for every async commit. This has a noticeable performance cost.
I don't think it is ever necessary to signal the wal writer here, unless wal writer is taking the long sleep for power saving purposes. If up to wal_writer_delay of "committed" transactions get lost on a crash, it doesn't really matter because they will be replayed again once replication resumes. However, might delaying the advance of the hot_standby_feedback by up to the amount of wal_writer_delay be a problem? I would think any set-up which depends on the standby never being a few dozen milliseconds behind is already doomed.
If I want to suppress signalling, what would be the right way to communicate to XLogSetAsyncXactLSN that it is being called in a subscription worker?
Another approach would be to make XLogSetAsyncXactLSN signalling less aggressive for everyone, not just subscription workers. There is no point in signalling it more than once for a given WriteRqstPtr page boundary. So each backend could locally remember the last boundary for which it signalled wal writer, and not signal again for the same boundary. This would be especially effective for a subscription worker, as it should be pretty common for almost all the async commits to be coming from the same process. Or, the last boundary could be kept in shared memory (XLogCtl) so all backends can share it, at the expense of additional work needed to be done under a spin lock.
Other ideas?
Thanks,
Jeff