| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
| Subject: | Vacuum timing in pg_stat_all_tables |
| Date: | 2025-03-04 14:12:18 |
| Message-ID: | CABUevEz9v1ZNToPyD98JnWDGZgG=SmPZKkSNzU9hXQ-nGTQF0g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
In light of bb8dff9995f (add cost delay time to progress views), looking at
the output of 30a6ed0ce4b (track per-relation time spent on vacuum and
analyze), it struck me as a bit unclear of what the time is really showing.
Do we want to do something similar for the table views? Or if not, we
should probably at least document the effect of cost based vacuum delay on
those timings - as in if they are including it or not (which I do believe
they are).
While more stats are always nice :), I think just being clear about it in
the docs would perhaps be enough for now? Maybe just appending something
along the line of "(including cost based delaying)"?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2025-03-04 14:19:35 | Re: what's going on with lapwing? |
| Previous Message | jian he | 2025-03-04 14:10:14 | Re: new commitfest transition guidance |