Message-ID: <gh-pgjdbc-pgjdbc-3693-c3027913979@github.com>
From: "Sanne (@Sanne)" <noreply+Sanne@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 02 Jul 2025 13:34:40 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock
In-Reply-To: <gh-pgjdbc-pgjdbc-3693@github.com>
References: <gh-pgjdbc-pgjdbc-3693@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: Sanne
X-GitHub-Comment-Id: 3027913979
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2025-07-02T13:36:15Z
X-GitHub-Issue: 3693
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693#issuecomment-3027913979
Content-Type: text/plain; charset=utf-8

> I'm not sure running with "deactivated locking" qualifies for "production-grade"

It's a good point. But as I mentioned in our architecture, such locks are totally redundant? Every connection instance is strictly scoped to a single thread. So I agree with you that one shouldn't be needing to set a JVM property, ideally our connection pool should be able to configure this semantics by default for all our users, and that would be our "production grade". 

> Apparently, the major part of ResourceLock overhead comes from [...]

These are excellent suggestions, thank you so much for looking!

I would totally agree that if we could avoid flags/configuration properties and simply reduce the overhead to a negligible amount that would be preferrable: the less tuning knobs the better.

But also bear in mind that we're competing with many other frameworks and languages, even other JVM based platforms which use different postgresql driver implementations, so I wouldn't want to see our user's CPUs (including in "production mode") spend time on unnecessary work.