Hi, On Tue, Oct 20, 2026 at 3:38 PM Manu <[email protected]> wrote: > > Hi Amit, > > Following up on my earlier mail about the uninitialized oldtup, I measured > v27 throughput to see which workloads non-streamed parallel apply speeds up. > The case I started from is the small-transaction / hot-counter pattern: many > tiny transactions, each updating one hot row or inserting a single row. > Setup: master 8e82d6610e72 + v27 0001-0012, -O2, publisher and subscriber on > one machine. > > Method: backlog drain. With the subscription disabled, 8 pgbench clients > commit 30,000 transactions; then ENABLE and time until a marker row committed > last becomes visible on the subscriber. Median of 3 rounds (5 where noted), > alternating order, VACUUM + CHECKPOINT before each drain. Ratios are against > max_parallel_apply_workers_per_subscription = 0.
Thank you for running these tests and sharing the result. Could you share a few more details about the workload you tested? A script would of course be great, but it would be more helpful to hear a bit more about the setup, for instance, what you mean by "updating the hot row" or the hot-counter pattern (it sounds like a dependency, but I may be misreading it). I'd also be curious about whether the table has an index, and roughly how large the subscriber table is, since both can affect replay. Similarly, the configuration of the test PostgreSQL instance can make a real difference, so if you could share that too, it helps. For context, we also noticed this sleep internally as a potential source of regression, as the XXX comment in the patch mentions, and we're planning to reduce its effect in a later version. And since our own earlier tests (without the pg_usleep()) didn't show a regression, we'd like to understand what differs in your environment. To that end, could you also share your machine's configuration when convenient? For performance test, we normally prefer to test on a more stable machine, which could be a more powerful one, so this is worth noting. Note that I haven't yet analyzed or addressed other comments received so far, as we're currently busy closing out other open items, so our replies and a new version of the patch may come a bit slowly at this stage. Please bear with us. We'll switch back to this once the other high-priority items are finished. Best Regards, Zhijie Hou
