Re: Force update_process_title=on in crash recovery? - Mailing list pgsql-hackers

From David Rowley
Subject Re: Force update_process_title=on in crash recovery?
Date
Msg-id CAApHDvp0i+paA+1ZGJcKwsn8R1GJYdmo=FNAB2F1pVTbA=u8CA@mail.gmail.com
Whole thread Raw
In response to Re: Force update_process_title=on in crash recovery?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 16 Sep 2020 at 17:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Hmm ... the thread leading up to 0921554 indicates that the performance
> penalty of update_process_title=on is just ridiculously large on Windows.
> Maybe those numbers are not relevant to crash recovery WAL-application,
> but it might be smart to actually measure that not just assume it.

I had a go at measuring this on Windows and couldn't really detect any
slowdown from running update_process_title on vs off. Average over 3
runs with update_process_title = off was 94.38 s, switched on the
average was 93.81 s. (Some noise there)

Adding a bit of logging shows that the process title was set 225
times. Once setting it to an empty string then once for each of the
224 segments replayed.

Also, from a pgbench -s test with update_process_title on and again
with off I see 9343 tps vs 11969 tps. The process title is changed
twice for each query, once to set it to the query and once to set it
to "idle". Doing a bit of maths there is seems that setting the
process title takes about 15 microseconds per call. So it would have
taken about 3.38 milliseconds to set the process title 225 times for
recovery, or if you prefer,  0.003609% additional overhead.

I don't think we'll notice.

David

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Bharath Rupireddy
Date:
Subject: Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away