From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: David Rowley <dgrowleyml@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep
 size
In-reply-to: <20220617062456.ahbwho67m7c3lnr3@alap3.anarazel.de>
References: <20220616233130.rparivafipt6doj3@alap3.anarazel.de>
 <CAApHDvo3GOUK2YFJTjcECvB=0Jx==S-ywcVno9U1rZT_7r7+dg@mail.gmail.com>
 <CAH2-WznM2gGO7O0w1sWYdBV3U6RLZvRhoWEr20+dS02QV3hqjA@mail.gmail.com>
 <CAApHDvqivvMw=AgvVQA+dKEQJHxV5JVS8Nm48NZA+FT8vuuDcw@mail.gmail.com>
 <20220617052228.mjwns6ugspihamsc@alap3.anarazel.de>
 <20220617062456.ahbwho67m7c3lnr3@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 16 Jun 2022 23:24:56 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1221362.1655476388.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Jun 2022 10:33:08 -0400
Message-ID: <1221363.1655476388@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1221363.1655476388%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> The remaining difference looks like it's largely caused by the
> enable_timeout_after(IDLE_STATS_UPDATE_TIMEOUT, ...) introduced as part =
of the
> pgstats patch. It's only really visible when I pin a single connection p=
gbench
> to the same CPU core as the server (which gives a ~16% boost here).

> It's not the timeout itself - that we amortize nicely (via 09cf1d522). I=
t's
> that enable_timeout_after() does a GetCurrentTimestamp().

> Not sure yet what the best way to fix that is.

Maybe not queue a new timeout if the old one is still active?

BTW, it looks like that patch also falsified this comment
(postgres.c:4478):

		 * At most one of these timeouts will be active, so there's no need to
		 * worry about combining the timeout.c calls into one.

Maybe fixing that end of things would be a simpler way of buying back
the delta.

> Or we could add a timeout.c API that specifies the timeout?

Don't think that will help: it'd be morally equivalent to
enable_timeout_at(), which also has to do GetCurrentTimestamp().

			regards, tom lane