Hi, On 2022-12-06 09:44:01 +0900, Kyotaro Horiguchi wrote: > At Mon, 5 Dec 2022 15:07:47 -0800, Andres Freund <and...@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. I'm most concerned about the overhead when the timeouts are *not* enabled. And this adds a branch to start_xact_command() and a function call for get_timeout_active(TRANSACTION_TIMEOUT) in that case. On its own, that's not a whole lot, but it does add up. There's 10+ function calls for timeout and ps_display purposes for every single statement. But it's definitely also worth optimizing the timeout enabled paths. And you're right, it looks like there's a fair bit of optimization potential. Greetings, Andres Freund