RE: Speed up transaction completion faster after many relations areaccessed in a transaction - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Date
Msg-id 0A3221C70F24FB45833433255569204D1FC4FA54@G01JPEXMBYT05
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Speed up transaction completion faster after many relations areaccessed in a transaction
List pgsql-hackers
From: David Rowley [mailto:david.rowley@2ndquadrant.com]
> I've revised the patch to add a new constant named
> LOCKMETHODLOCALHASH_SHRINK_SIZE. I've set this to 64 for now. Once the hash

Thank you, and good performance.  The patch passed make check.

I'm OK with the current patch, but I have a few comments.  Please take them as you see fit (I wouldn't mind if you
don't.)


(1)
+#define LOCKMETHODLOCALHASH_SHRINK_SIZE 64

How about LOCKMETHODLOCALHASH_SHRINK_THRESHOLD, because this determines the threshold value to trigger shrinkage?  Code
inPostgreSQL seems to use the term threshold.
 


(2)
+/* Complain if the above are not set to something sane */
+#if LOCKMETHODLOCALHASH_SHRINK_SIZE < LOCKMETHODLOCALHASH_INIT_SIZE
+#error "invalid LOCKMETHODLOCALHASH_SHRINK_SIZE"
+#endif

I don't think these are necessary, because these are fixed and not configurable.  FYI, src/include/utils/memutils.h
doesn'thave #error to test these macros.
 

#define ALLOCSET_DEFAULT_MINSIZE   0
#define ALLOCSET_DEFAULT_INITSIZE  (8 * 1024)
#define ALLOCSET_DEFAULT_MAXSIZE   (8 * 1024 * 1024)


(3)
+    if (hash_get_num_entries(LockMethodLocalHash) == 0 &&
+        hash_get_max_bucket(LockMethodLocalHash) >
+        LOCKMETHODLOCALHASH_SHRINK_SIZE)
+        CreateLocalLockHash();

I get an impression that Create just creates something where there's nothing.  How about Init or Recreate?


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Next
From: Shawn Wang
Date:
Subject: Re: Problem with default partition pruning