Horton
Menu

Re: Add progressive backoff to XactLockTableWait functions

Xuneng Zhou <xunengzhou@gmail.com>

View thread
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-17T13:38:18Z
Lists: pgsql-hackers

Attachments

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.


2. Flame‐graph
See attached files

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 →

  1. Allow logical decoding on standbys