| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | Kevin K Biju <kevinkbiju(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add progressive backoff to XactLockTableWait functions |
| Date: | 2025-06-17 13:38:18 |
| Message-ID: | CABPTF7Wqv99W5VXCBu5WE_QwRKC5SRcYnLnxTT2DE7E_QkOU1Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| 1s-threshold.svg | image/svg+xml | 99.7 KB |
| exp_backoff.svg | image/svg+xml | 103.4 KB |
| head.svg | image/svg+xml | 113.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2025-06-17 13:40:27 | Fix copy-and-past thinko (src/interfaces/libpq/fe-cancel.c) |
| Previous Message | Dimitrios Apostolou | 2025-06-17 13:37:41 | Re: --enable-{debug,cassert} should also activate --enable-depend |
