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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Дата
Msg-id CAKJS1f-=wBq7kXbyLQJ3Lw+=K0ZmSOPwb6YFxx1Y1LVHu_ffog@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Speed up transaction completion faster after many relations areaccessed in a transaction  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы Re: Speed up transaction completion faster after many relations are accessed in a transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, 23 Jul 2019 at 15:47, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> OTOH, how about my original patch that is based on the local lock list?  I expect that it won't that significant
slowdownin the same test case.  If it's not satisfactory, then v6 is the best to commit.
 

I think we need to move beyond the versions that have been reviewed
and rejected. I don't think the reasons for their rejection will have
changed.

I've attached v7, which really is v6 with some comments adjusted and
the order of the hash_get_num_entries and hash_get_max_bucket function
calls swapped.  I think hash_get_num_entries() will return 0 most of
the time where we're calling it, so it makes sense to put the
condition that's less likely to be true first in the if condition.

I'm pretty happy with v7 now. If anyone has any objections to it,
please speak up very soon.  Otherwise, I plan to push it about this
time tomorrow.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add parallelism and glibc dependent only options to reindexdb
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: initdb recommendations