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