Message-ID: From: "davecramer (@davecramer)" To: "pgjdbc/pgjdbc" Date: Wed, 02 Jul 2025 15:34:52 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock In-Reply-To: References: List-Id: X-GitHub-Author-Login: davecramer X-GitHub-Comment-Id: 3028326304 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3693 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693#issuecomment-3028326304 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. I'm curious what other driver implementations they use ? Do you know ?