Hello, At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote in <565fd0ba.5020...@lab.ntt.co.jp> > On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote: > > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera > > <alvhe...@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.
Sorry I misunderstood the patch. Agreed. The patch already separates integer values and texts. And re-reviewing the patch, there's no fields necessary to be passed as string. total_heap_pages, scanned_heap_pages, total_index_pages, scanned_index_pages, vacrelstats->num_index_scans are currently in int32. Phase can be in integer, and schema_name and relname can be represented by one OID, uint32. Finally, *NO* text field is needed at least this usage. So progress_message is totally useless regardless of other usages unknown to us. Am I missing somethig? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers