RE: Speed up transaction completion faster after many relations are accessed in a transaction

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, "'Simon Riggs'" <simon(at)2ndquadrant(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Speed up transaction completion faster after many relations are accessed in a transaction
Date: 2019-02-20 06:20:37
Message-ID: 0A3221C70F24FB45833433255569204D1FB9E2E9@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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(at)anarazel(dot)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(at)2ndquadrant(dot)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 Content-Type Size
faster-locallock-scan_v2.patch application/octet-stream 6.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Shaplov 2019-02-20 06:38:03 Re: [PATCH][PROPOSAL] Add enum releation option type
Previous Message Masahiko Sawada 2019-02-20 06:14:07 Re: Prepared transaction releasing locks before deregistering its GID