On Thu, Mar 04, 2021 at 12:53:54PM -0500, Tom Lane wrote: > My conclusion is that we don't need to do anything, indeed the proposed > changes will probably just lead to overestimation. > > It's certainly possible that there's something amiss somewhere. These > numbers were all taken with out-of-the-box configuration, so it could be > that changing some postgresql.conf entries would expose that some module > is not scaling its request correctly. Also, I don't have any extensions > loaded, so this proves nothing about the correctness of any of those. > But it appears to me that the general scheme is working perfectly fine, > so we do not need to complicate it.
Thanks for looking at it. I agree that most of the changes aren't worth the complication and risk to overestimate the shmem size. But I did some more experiments comparing the current version and the patched version of the lock and pred lock shared hash table size estimations with some configuration changes, and I find the following delta in the estimated size: - original configuration : 15kB - max_connection = 1000 : 30kB - max_connection = 1000 and max_locks_per_xact = 256 : 96kB I don't know if my version is totally wrong or not, but if it's not it could be worthwhile to apply the hash tab part as it would mean that it doesn't scale properly.
