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

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: Speed up transaction completion faster after many relations areaccessed in a transaction
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FBF2D3B@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
Следующее
От: Tom Lane
Дата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation