Re: Add progressive backoff to XactLockTableWait functions
Xuneng Zhou <xunengzhou@gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Kevin K Biju <kevinkbiju@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-06-17T14:02:49Z
Lists: pgsql-hackers
Attachments
- hardware_counter_results.png (image/png)
Hi, On Tue, Jun 17, 2025 at 9:38 PM Xuneng Zhou <xunengzhou@gmail.com> wrote: > Hi, > > Although it’s clear that replacing tight 1 ms polling loops will reduce > CPU usage, I'm curious about the hard numbers. To that end, I ran a 60 s > logical-replication slot–creation workload on a standby using three > different XactLockTableWait() variants—on an 8-core, 16 GB AMD system—and > collected both profiling traces and hardware-counter metrics. > > > 1. Hardware‐counter results > > > [image: image.png] > > > - CPU cycles drop by 58% moving from 1 ms to exp. backoff, and another > 25% to the 1 s threshold variant. > - Cache‐misses and context‐switches see similarly large reductions. > - IPC remains around 0.45, dipping slightly under longer sleeps. > > Gmail does not seem to support embedded images, so I’ve included it as an attachment. Best regards, Xuneng
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical decoding on standbys
- 0fdab27ad68a 16.0 cited