pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Ranier Vilela <ranier.vf@gmail.com>
Cc: ldh@laurent-hasson.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Date: Sun, 22 Aug 2021 13:50:32 -0400
Message-ID: <30496.1629654632@sss.pgh.pa.us> (raw)
In-Reply-To: <20210822154758.GZ10479@telsasoft.com>
References: <MN2PR15MB2560AE2A878FBBE88DCFF33385C29@MN2PR15MB2560.namprd15.prod.outlook.com>
	<2092859.1629558281@sss.pgh.pa.us>
	<MN2PR15MB25607BDC72A325CA9B9D3E3385C29@MN2PR15MB2560.namprd15.prod.outlook.com>
	<2136207.1629569846@sss.pgh.pa.us>
	<20210821191950.GW10479@telsasoft.com>
	<MN2PR15MB2560ED2A8F967B14E7D7881E85C29@MN2PR15MB2560.namprd15.prod.outlook.com>
	<20210821221729.GY10479@telsasoft.com>
	<MN2PR15MB2560FB03666CEABB651FB32185C29@MN2PR15MB2560.namprd15.prod.outlook.com>
	<MN2PR15MB256034533A31A7C11E3C347985C39@MN2PR15MB2560.namprd15.prod.outlook.com>
	<CAEudQAocYZieAMgCtXa8Oau8=dVJ1_R1r0coLeF1LfiYkBCTNA@mail.gmail.com>
	<20210822154758.GZ10479@telsasoft.com>

Justin Pryzby <pryzby@telsasoft.com> writes:
> This looks useful, thanks.  It seems like maybe win64 builds are very slow
> running this:

> exec_stmt_block() /
> BeginInternalSubTransaction() /
> AbortSubTransaction() /
> reschedule_timeouts() /
> schedule_alarm() / 
> setitimer() /
> pg_timer_thread() /
> WaitForSingleObjectEx () 

Hmm ... we should not be there unless there are active timeout events,
which there aren't by default.  I wonder whether either Ranier or
Laurent have statement_timeout or some similar option enabled.

I tried setting statement_timeout = '1 min' just to see if that
would affect the results.  It does, but only incrementally on
my Linux box (on v13, the exception-causing query slows from
~13sec to ~14sec).  It's possible that our Windows version of
setitimer() is far slower, but that doesn't make a lot of
sense really --- the client side of that just briefly takes
a critical section.  It shouldn't be blocking.

Also, the Windows version (src/backend/port/win32/timer.c)
hasn't changed at all since before v11.  So even if it's
slow, that doesn't tell us what changed.

There is a patch in v14 (09cf1d522) that drastically reduces
the rate at which we make setitimer() calls, which would likely
be enough to fix any performance problem that may exist here.
But it's still unclear what's different between v11 and v13.

			regards, tom lane





view thread (78+ messages)  latest in thread

Message-ID: <30496.1629654632@sss.pgh.pa.us>
Permalink:  ../30496.1629654632@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/30496.1629654632@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pryzby@telsasoft.com, ranier.vf@gmail.com, ldh@laurent-hasson.com
  Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  In-Reply-To: <30496.1629654632@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox