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

From Tom Lane
Subject Re: Force update_process_title=on in crash recovery?
Date
Msg-id 1443723.1600235012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Force update_process_title=on in crash recovery?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Force update_process_title=on in crash recovery?  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Sep 16, 2020 at 2:30 PM Michael Paquier <michael@paquier.xyz> wrote:
>> Another thing to be careful here is WIN32, see 0921554.  And slowing
>> down recovery is never a good idea.

> Right, that commit makes a lot of sense because it suppresses many
> system calls that happen for each query.  The same problem existed on
> older FreeBSD versions and I saw that costing ~10% of TPS on read-only
> pgbench.  In other commits I've been removing system calls that happen
> for every WAL record.  But in this thread I'm talking about an update
> per 16MB WAL file, which seems like an acceptable ratio to me.

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.

In any case, I'd recommend setting up any patch you create for this
to be easily "ifndef WIN32"'d in case we change our minds on the
point later.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Force update_process_title=on in crash recovery?
Next
From: Paul Guo
Date:
Subject: Re: Parallelize stream replication process