On Thu, Feb 5, 2026 at 8:13 AM Pavlo Golub <[email protected]> wrote: > pg_current_vxact_id() complexity is O(1) with direct memory reads and > no locks, while querying pg_locks requires O(n) where n is the number > of locks, among these operations are constructing tuples then > filtering. For me it's obviously more work. The proposed function is > essentially free compared to pg_locks querying.
I agree with this and would be inclined to accept the patch. I have reviewed the v3 patch and I didn't see anything wrong with it. I think it could be committed if we were not in feature freeze, and of course provided that we had consensus. > I'd appreciate thoughts from others in the community on whether this > reasoning is compelling. I think the only thing I find slightly less than compelling about this reasoning is that it's all theoretical. If you said, look, we tried the pg_locks method in our environment and the performance was demonstrably bad, and then we wrote an extension that does the same thing as this function and then the performance was good, that would be a much stronger argument in my mind. Otherwise, someone might hypothesize that the performance gap that you point out here, while almost certainly read in and of itself, is not something that anyone has a real-world reason to care about. I do sometimes have concerns about adding a whole bunch of functions to the default install that can theoretically be justified but in reality get very little use. In general I think the bar for adding stuff like this should be fairly low, but I also wonder how many people would really be sad if we were missing, e.g., asinh() or pg_get_tablespace_ddl() or pg_sleep_until(), just to pick a few examples of things that have failed to win my unqualified confidence over the years. I'm not saying any of those were necessarily bad things for us to accept; the use case isn't nothing, and asinh() is apparently even in the SQL standard. At the same time, I bet the percentage of installs that will ever use any of them is real small. -- Robert Haas EDB: http://www.enterprisedb.com
