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

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 →
  1. Allow logical decoding on standbys