Re: [PROPOSAL] VACUUM Progress Checker.
От | Amit Langote |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | 565FD0BA.5020202@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [PROPOSAL] VACUUM Progress Checker.
|
Список | pgsql-hackers |
On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote: > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera <alvherre@2ndquadrant.com> wrote >> >> Actually, do we really need to have the table name as a string at all >> here? Why not just report the table OID? Surely whoever wants to check >> the progress can connect to the database in question to figure out the >> table name. > > I thought the same thing but found that the same kind of view > (say, pg_stat_user_tables) has separate relanme and shcemaname in > string (not a qualified name, though). > > Apart from the representation of the relation, OID would be > better as a field in beentry. I wonder if the field should be a standalone field or as yet another st_progress_* array? IMHO, there are some values that a command would report that should not be mixed with pgstat_report_progress()'s interface. That is, things like command ID/name, command target (table name or OID) should not be mixed with actual progress parameters like num_pages, num_indexes (integers), processing "phase" (string) that are shared via st_progress_* fields. The first of them already has its own reporting interface in proposed patch in the form of pgstat_report_activity_flag(). Although, we must be careful to choose these interfaces carefully. Thanks, Amit
В списке pgsql-hackers по дате отправления: