Re: Track the amount of time waiting due to cost_delay

I spent some time preparing v12 for commit and made the following larger
changes:

* I renamed the column to delay_time and changed it back to repoting
milliseconds to match other stats views like pg_stat_io.

* I optimized the code in vacuum_delay_point a bit. Notably, we're now
just storing the nanoseconds value in the pgstat param, so we now have to
divide by 1,000,000 in the views.

* I added a track_cost_delay_timing parameter that is off by default. The
new timing code is only used when this parameter is turned on. This is
meant to match parameters like track_io_timing. I felt that this was
important since this is relatively hot code.

* I also added delay_time to pg_stat_progress_analyze. It seems to use the
same vacuum_delay_point() function, so we actually need to do a bit of
refactoring to make sure the right pgstat param is incremented.

I think this has been discussed in the thread a bit already, but I do think
we should consider also adding this information to the vacuum/analyze log
messages and to the output of VACUUM/ANALYZE (VERBOSE). That needn't hold
up this patch, though.

Finally, I can't help but feel that the way we are adding this information
is a bit weird, both in how we are doing it and where we are presenting the
results. I don't see any reason that pgstat_progress_incr_param() and
friends can't handle this information, but I don't see any existing uses
for timing information. Plus, IMHO it's debatable whether the delay time
is really "progress" information, although I haven't thought of a better
place (existing or new) for it.

Thoughts?

--
nathan