From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>, rahilasyed90(at)gmail(dot)com, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Masao Fujii <masao(dot)fujii(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, pokurev(at)pm(dot)nttdata(dot)co(dot)jp, Vinayak Pokale <vinpokale(at)gmail(dot)com> |
Subject: | Re: [PROPOSAL] VACUUM Progress Checker. |
Date: | 2015-12-10 06:10:16 |
Message-ID: | 56691748.1020608@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/12/10 4:40, Robert Haas wrote:
> It's going to be *really* important that this facility provides a
> lightweight way of updating progress, so I think this whole API is
> badly designed. VACUUM, for example, is going to want a way to update
> the individual counter for the number of pages it's scanned after
> every page. It should not have to pass all of the other information
> that is part of a complete report. It should just be able to say
> pgstat_report_progress_update_counter(1, pages_scanned) or something
> of this sort. Don't marshal all of the data and then make
> pgstat_report_progress figure out what's changed. Provide a series of
> narrow APIs where the caller tells you exactly what they want to
> update, and you update only that. It's fine to have a
> pgstat_report_progress() function to update everything at once, for
> the use at the beginning of a command, but the incremental updates
> within the command should do something lighter-weight.
How about something like the following:
/*
* index: in the array of uint32 counters in the beentry
* counter: new value of the (index+1)th counter
*/
void pgstat_report_progress_update_counter(int index, uint32 counter);
/*
* msg: new value of (index+1)the message (with trailing null byte)
*/
void pgstat_report_progress_update_message(int index, const char *msg);
Actually updating a counter or message would look like:
pgstat_increment_changecount_before(beentry);
// update the counter or message at index in beentry->st_progress_*
pgstat_increment_changecount_after(beentry);
Other interface functions which are called at the beginning:
void pgstat_report_progress_set_command(int commandId);
void pgstat_report_progress_set_command_target(const char *target_name);
or
void pgstat_report_progress_set_command_target(Oid target_oid);
And then a SQL-level,
void pgstat_reset_local_progress();
Which simply sets beentry->st_command to some invalid value which signals
a progress view function to ignore this backend.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2015-12-10 06:14:01 | Re: pg_hba_lookup function to get all matching pg_hba.conf entries |
Previous Message | Michael Paquier | 2015-12-10 05:52:49 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |