Re: Transaction timeout
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: andres@anarazel.de
Cc: amborodin86@gmail.com, samokhvalov@gmail.com,
pgsql-hackers@postgresql.org
Date: 2022-12-06T00:44:01Z
Lists: 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
Commits
-
Add TAP tests for timeouts
- eeefd4280f6e 17.0 landed
-
Remove flaky isolation tests for timeouts
- a661bf7b0f56 17.0 landed
-
Followup fixes for transaction_timeout
- bf82f43790a6 17.0 landed
-
Introduce transaction_timeout
- 51efe38cb92f 17.0 landed
-
On systems that have setsid(2) (which should be just about everything except
- 3ad0728c817b 8.2.0 cited