track_io_timing default setting - Mailing list pgsql-hackers

From Jeff Janes
Subject track_io_timing default setting
Date
Msg-id CAMkU=1z8M_toC7JigMnhanqme4VnEwufWX9JR+xw9JBh7n-RpA@mail.gmail.com
Whole thread Raw
Responses RE: track_io_timing default setting  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Re: track_io_timing default setting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Can we change the default setting of track_io_timing to on?

I see a lot of questions, such as over at stackoverflow or dba.stackexchange.com, where people ask for help with plans that would be much more useful were this on.  Maybe they just don't know better, maybe they can't turn it on because they are not a superuser.

I can't imagine a lot of people who care much about its performance impact will be running the latest version of PostgreSQL on ancient/weird systems that have slow clock access. (And the few who do can just turn it off for their system).

For systems with fast user-space clock access, I've never seen this setting being turned on make a noticeable dent in performance.  Maybe I just never tested enough in the most adverse scenario (which I guess would be a huge FS cache, a small shared buffers, and a high CPU count with constant churning of pages that hit the FS cache but miss shared buffers--not a system I have handy to do a lot of tests with.)

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side