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 0A3221C70F24FB45833433255569204D1FBF2D3B@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]
> It would be good to get your view on the
> shrink_bloated_locallocktable_v3.patch I worked on last night. I was
> unable to measure any overhead to solving the problem that way.

Thanks, it looks super simple and good.  I understood the idea behind your patch is:

* Transactions that touch many partitions and/or tables are a special event and not normal, and the hash table bloat is
anunlucky accident.  So it's reasonable to revert the bloated hash table back to the original size.
 

* Repeated transactions that acquire many locks have to enlarge the hash table every time.  However, the overhead of
hashtable expansion should be hidden behind other various processing (acquiring/releasing locks, reading/writing the
relations,accessing the catalogs of those relations)
 


TBH, I think the linked list approach feels more intuitive because the resulting code looks what it wants to do
(efficientlyiterate over acquired locks) and is based on the classic book.  But your approach seems to relieve people.
SoI'm OK with your patch.
 

I'm registering you as another author and me as a reviewer, and marking this ready for committer.


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
Next
From: Tom Lane
Date:
Subject: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation