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 0A3221C70F24FB45833433255569204D1FB9E2E9@G01JPEXMBYT05
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Speed up transaction completion faster after many relations areaccessed in a transaction
List pgsql-hackers
From: Tom Lane [mailto:tgl@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:andres@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:simon@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


Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Prepared transaction releasing locks before deregistering its GID
Next
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH][PROPOSAL] Add enum releation option type