Re: Force update_process_title=on in crash recovery?

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Christoph Berg <myon(at)debian(dot)org>
Subject: Re: Force update_process_title=on in crash recovery?
Date: 2020-09-17 06:43:37
Message-ID: CAApHDvp0i+paA+1ZGJcKwsn8R1GJYdmo=FNAB2F1pVTbA=u8CA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 16 Sep 2020 at 17:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
details.txt text/plain 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-09-17 06:44:20 Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
Previous Message Michael Paquier 2020-09-17 05:57:30 Re: Minimal logical decoding on standbys