Re: Transaction timeout - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Transaction timeout
Date
Msg-id 20221206.094401.857223078395325678.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Transaction timeout  (Andres Freund <andres@anarazel.de>)
Responses Re: Transaction timeout  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Arne Roland
Date:
Subject: Re: missing indexes in indexlist with partitioned tables
Next
From: Ian Lawrence Barwick
Date:
Subject: Re: doc: add missing "id" attributes to extension packaging page