Subject: Add pg_stat_progress_rewrite view.

From: Kirill Reshke <[email-masked]>
Date: Wed, 4 Dec 2024 19:53:04 +0500

Hi hackers!

Recently, one administrator asked me how to monitor the progress of
his ALTER TABLE... ALTER COLUMN TYPE bigint.

That leads me to believe that consumers might benefit from having an
API to track the table change process.

PFA draft patch adding number of tuples (tuples_processed) that was
read from the altered table.

Thoughts?

-- 
Best regards,
Kirill Reshke

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 4 Dec 2024 18:01:47 +0100

Hello,

> API to track the table change process.

I agree that tracking progress of a table rewrite is useful, so +1 for
the feature in general.

> read from the altered table.

I'm not sure that this is very usable though, because the user would
have to know how many tuples the table originally had before they can
make any sense of this number.  Maybe in addition to that number, we can
show the total number of pages of the old relation as well as the number
of pages scanned so far.  That way, the user knows what fraction of the
old table has already been scanned.  In addition, but I'm not sure sure
aobut this one, it may also be useful to show the number of pages
written in the new relation.  (It lets you see how better packed the new
copy is.)

Do we also need to show metrics about the associated toast table?
There's no concept of "how many pages we've scanned" for the toast
table, but we could say how many pages the old one has vs. how many
we've written in the new one so far.  Though, again, that may not say a
lot.

On the other hand, IIRC we also create indexes after the heap rewrite
itself is complete, so we should show the progress of that part of the
process as well.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"La persona que no quería pecar / estaba obligada a sentarse
 en duras y empinadas sillas    / desprovistas, por cierto
 de blandos atenuantes"                          (Patricio Vogel)