On Wed, Feb 8, 2023 at 7:18 PM Andres Freund <and...@anarazel.de> wrote: > > This is a good thing for performance, of course, but it also makes VACUUM > > VERBOSE show information that makes sense to users, since things actually > > happen in a way that makes a lot more sense. I'm quite happy about the fact > > that the new VACUUM VERBOSE allows users to mostly ignore obscure details > > like whether an index was scanned by amvacuumcleanup() or by ambulkdelete() > > -- stuff that basically nobody understands. That seems worth preserving. > > I don't mind making the messages as similar as possible, but I do mind if I as > a postgres hacker, or an expert consultant, can't parse that detail out. We > need to be able to debug things like amvacuumcleanup() doing too much work too > often.
FWIW you can tell even today. You can observe that the number of index scans is 0, and that one or more indexes have their size reported -- that indicates that an amvacuumcleanup()-only scan took place, say because we needed to put some preexisting deleted pages in the FSM. There is also another detail that strongly hints that VACUUM VERBOSE had to scan an index during its call to amvacuumcleanup(), which is atypical: it only shows details for that particular index, which is really noticeable. It won't report anything about those indexes that had no-op calls to amvacuumcleanup(). It kind of makes sense that we report 0 index scans when there were 0 calls to ambulkdelete(), even though there may still have been some index scans during a call to some amvacuumcleanup() routine. The common case is that they're no-op calls for every index, but even when they're not there is still probably only one or two indexes that have to do a noticeable amount of I/O. It makes sense to "round down to 0". Granted, there are some notable exceptions. For example, gistvacuumcleanup() doesn't even try to avoid scanning the index. But that's really a problem in gistvacuumcleanup() -- since it really doesn't make very much sense, even from a GiST point of view. It can follow exactly the same approach as B-Tree here, since its approach to page deletion is already directly based on nbtree. -- Peter Geoghegan