Re: effective_io_concurrency's steampunk spindle maths
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-09T23:20:31Z
Lists: pgsql-hackers
Attachments
- 0001-Simplify-the-effective_io_concurrency-setting.patch (text/x-patch) patch 0001
- 0002-Introduce-a-maintenance_io_concurrency-setting.patch (text/x-patch) patch 0002
On Sat, Mar 7, 2020 at 9:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > > So I think we should either rename e_i_c or keep it as is, and then also > > have a new GUC. And then translate the values between those (but that > > might be overkill). > > Please DON'T try to have two interrelated GUCs for this. We learned > our lesson about that years ago. Ack. > I think dropping the existing GUC is a perfectly sane thing to do, > if the new definition wouldn't be compatible. In practice few > people will notice, because few will have set it. That's what I thought too, but if Andres is right that "it's not like anybody knew how to infer a useful value", I'm wondering it's enough if we just provide an explanation of the change in the release notes. The default doesn't change (1 goes to 1), so most people will experience no change, but it you had it set to (say) 42 after careful experimentation, you might like to consider updating it to the result of: select round(sum(42 / n::float)) as new_setting from generate_series(1, 42) s(n) Here's a patch set to remove the spindle stuff, add a maintenance variant, and use the maintenance one in heap_compute_xid_horizon_for_tuples().
Commits
-
Introduce a maintenance_io_concurrency setting.
- fc34b0d9de27 13.0 landed
-
Simplify the effective_io_concurrency setting.
- b09ff53667ff 13.0 landed