Re: .ready and .done files considered harmful
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Dipesh Pandit <dipesh.pandit@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>,
Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Hannu Krosing <hannuk@google.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-09-20T20:25:09Z
Lists: pgsql-hackers
On Thu, Sep 16, 2021 at 7:26 PM Bossart, Nathan <bossartn@amazon.com> wrote: > 1. I've removed several calls to PgArchForceDirScan() in favor of > calling it at the top of pgarch_ArchiverCopyLoop(). I believe > there is some disagreement about this change, but I don't think > we gain enough to justify the complexity. The main reason we > exit pgarch_ArchiverCopyLoop() should ordinarily be that we've > run out of files to archive, so incurring a directory scan the > next time it is called doesn't seem like it would normally be too > bad. I'm sure there are exceptions (e.g., lots of .done files, > archive failures), but the patch is still not making things any > worse than they presently are for these cases. I was thinking that this might increase the number of directory scans by a pretty large amount when we repeatedly catch up, then 1 new file gets added, then we catch up, etc. But I guess your thought process is that such directory scans, even if they happen many times per second, can't really be that expensive, since the directory can't have much in it. Which seems like a fair point. I wonder if there are any situations in which there's not much to archive but the archive_status directory still contains tons of files. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Reduce overhead of renaming archive status files.
- 756e221db610 16.0 cited
-
Improve performance of pgarch_readyXlog() with many status files.
- beb4e9ba1652 15.0 landed
-
Prioritize history files when archiving
- b981df4cc09a 12.0 cited