Re: [PROPOSAL] VACUUM Progress Checker.

Hello,

At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote in <565FD0BA(dot)5020202(at)lab(dot)ntt(dot)co(dot)jp>
> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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