Could you explain how the adaptive parameters were selected? In particular, I have a few questions about the polling limit and its interaction with the existing spin-delay mechanism. 1. Why is 256 an appropriate maximum polling interval? A fixed limit seems reasonable, but the patch does not explain why 256 is preferable to a smaller value. This trades fewer state reads for slower detection of lock release, and the duration of 256 iterations varies across processors. Could you share comparisons with smaller limits, including acquisition latency as well as throughput? It would be useful to know whether the improvement holds over a broad range of values or depends on this particular setting. A short comment explaining the selection would also help future maintenance. Similarly, how were the threshold of 5 and the +5/-1 adjustment chosen? Since lock_read_count decreases as the polling interval increases, what behavior is the controller intended to converge to? 2. Could the polling interval cause unnecessary sleeps? perform_spin_delay() also calls pg_usleep(). If the polling interval exceeds spins_per_delay, the loop can sleep repeatedly without checking whether the lock has already been released. For example, with an interval of 256 and spins_per_delay of 10, there are 25 sleeps before the first reread. In a control-flow reproduction, this continued after immediate lock release; near the delay limit, it could also reach s_lock_stuck() before observing the release. Would it make sense to reread the state after every sleep and coordinate polling with the transition from active spinning to sleeping? 3. How does the adaptation recover when contention subsides? The interval is backend-local and applies to unrelated LWLocks. Successful uncontended acquisitions do not decrease it, so a value learned from one heavily contended lock can persist into later operations. Could you include a workload transition from sustained contention to brief contention? This would help assess whether the +5/-1 adjustment recovers quickly enough. 4. Why does this optimization need to change the global sleep minimum? Changing MIN_DELAY_USEC affects every caller of perform_spin_delay(), including ordinary spinlocks and buffer-header waits.This will lead to opposition from many core team members, Those paths will also get shorter initial and reset sleeps, potentially changing CPU usage and behavior when a lock holder is descheduled. Could this LWLock optimization retain the existing global delay? If the shorter delay is necessary, could you explain that dependency and provide results covering the other affected callers? The LWLock benchmark alone leaves their behavior unclear.
