Re: [PROPOSAL] VACUUM Progress Checker.

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, alvherre(at)2ndquadrant(dot)com
Cc: rahilasyed90(at)gmail(dot)com, Jim(dot)Nasby(at)bluetreble(dot)com, pgsql-hackers(at)postgresql(dot)org, masao(dot)fujii(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, thom(at)linux(dot)com, pokurev(at)pm(dot)nttdata(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, vinpokale(at)gmail(dot)com
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-12-03 05:18:50
Message-ID: 565FD0BA.5020202@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-12-03 05:53:30 Re: psql: add \pset true/false
Previous Message David Rowley 2015-12-03 05:18:35 Re: Parallel Aggregate