Re: Transaction timeout

Hi,

On 2022-12-06 09:44:01 +0900, Kyotaro Horiguchi wrote:
> At Mon, 5 Dec 2022 15:07:47 -0800, Andres Freund <andres(at)anarazel(dot)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