Re: Transaction timeout

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Transaction timeout
Дата
Msg-id 20221206.094401.857223078395325678.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Transaction timeout  (Andres Freund <andres@anarazel.de>)
Ответы Re: Transaction timeout  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
At Mon, 5 Dec 2022 15:07:47 -0800, Andres Freund <andres@anarazel.de> wrote in 
> I'm a bit worried about adding evermore branches and function calls for
> the processing of single statements. We already spend a noticable
> percentage of the cycles for a single statement in PostgresMain(), this
> adds additional overhead.
> 
> I'm somewhat inclined to think that we need some redesign here before we
> add more overhead.

insert_timeout() and remove_timeout_index() move 40*(# of several
timeouts) bytes at every enabling/disabling a timeout. This is far
frequent than actually any timeout fires. schedule_alarm() is
interested only in the nearest timeout.

So, we can get rid of the insertion sort in
insert_timeout/remove_timeout_index then let them just search for the
nearest one and remember it. Finding the nearest should be faster than
the insertion sort. Instead we need to scan over the all timeouts
instead of the a few first ones, but that's overhead is not a matter
when a timeout fires.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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

Предыдущее
От: Arne Roland
Дата:
Сообщение: Re: missing indexes in indexlist with partitioned tables
Следующее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: doc: add missing "id" attributes to extension packaging page