From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Hm. Putting a list header for a purely-local data structure into shared > memory seems quite ugly. Isn't there a better place to keep that?
Agreed. I put it in the global variable. > Do we really want a dlist here at all? I'm concerned that bloating > LOCALLOCK will cost us when there are many locks involved. This patch > increases the size of LOCALLOCK by 25% if I counted right, which does > not seem like a negligible penalty. To delete the LOCALLOCK in RemoveLocalLock(), we need a dlist. slist requires the list iterator to be passed from callers. From: Andres Freund [mailto:and...@anarazel.de] > Sure, we should do that. I don't buy the "illogical" bit, just moving > hashcode up to after tag isn't more or less logical, and saves most of > the padding, and moving the booleans to the end isn't better/worse > either. > > I don't find Thanks, I've done it. From: Simon Riggs [mailto:si...@2ndquadrant.com] > Can we use our knowledge of the structure of locks, i.e. partition locks > are all children of the partitioned table, to do a better job? I couldn't come up with a idea. Regards Takayuki Tsunakawa
faster-locallock-scan_v2.patch
Description: faster-locallock-scan_v2.patch
