Hello,
On 2024-Dec-04, Kirill Reshke wrote:
> 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.
I agree that tracking progress of a table rewrite is useful, so +1 for
the feature in general.
> PFA draft patch adding number of tuples (tuples_processed) that was
> 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)
