Re: [PROPOSAL] VACUUM Progress Checker.
От | Amit Langote |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | 56691748.1020608@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Robert Haas <robertmhaas@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: