Re: [PROPOSAL] VACUUM Progress Checker.
| От | Vinayak Pokale |
|---|---|
| Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
| Дата | |
| Msg-id | CAEySZviETh-ghB5JNx6ARzK9U7weN566K=r6fFhhijVGxk0MhQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [PROPOSAL] VACUUM Progress Checker.
(Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: [PROPOSAL] VACUUM Progress Checker. (Sudhir Lonkar-2 <sudhir.lonkar@nttdata.com>) |
| Список | pgsql-hackers |
Hi,
Please find attached patch addressing following comments.
>The relation OID should be reported and not its name. In case of a
>relation rename that would not be cool for tracking, and most users
>are surely going to join with other system tables using it.
The relation OID is reported instead of relation name.
The following interface function is called at the beginning to report the relation OID once.
void pgstat_report_command_target(Oid relid)
>Regarding pg_stat_get_vacuum_progress(): I think a backend can simply be
>skipped if (!has_privs_of_role(GetUserId(), beentry->st_userid)) (cannot
>put that in plain English, :))
Updated in the attached patch.
In the previous patch, ACTIVITY_IS_VACUUM is set unnecessarily for VACOPT_FULL and they are not covered by lazy_scan_heap().
I have updated it in attached patch and also renamed ACTIVITY_IS_VACUUM to COMMAND_LAZY_VACUUM.
Added documentation for view.
Some more comments need to be addressed.
Regards,
Vinayak Pokale
It's not a hard requirement, but it should be quite easy to do withoutOn Fri, Dec 11, 2015 at 1:25 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> For another thing, there are definitely going to be
>> some people that want the detailed information - and I can practically
>> guarantee that if we don't make it available, at least one person will
>> write a tool that tries to reverse-engineer the detailed progress
>> information from whatever we do report.
>
> OK, so this justifies the fact of having detailed information, but
> does it justify the fact of having precise and accurate data? ISTM
> that having detailed information and precise information are two
> different things. The level of details is defined depending on how
> verbose we want the information to be, and the list you are giving
> would fulfill this requirement nicely for VACUUM. The level of
> precision/accuracy at which this information is provided though
> depends at which frequency we want to send this information. For
> long-running VACUUM it does not seem necessary to update the fields of
> the progress tracker each time a counter needs to be incremented.
> CLUSTER has been mentioned as well as a potential target for the
> progress facility, but it seems that it enters as well in the category
> of things that would need to be reported on a slower frequency pace
> than "each-time-a-counter-is-incremented".
>
> My impression is just based on the needs of VACUUM and CLUSTER.
> Perhaps I am lacking imagination regarding the potential use cases of
> the progress facility though in cases where we'd want to provide
> extremely precise progress information :)
> It just seems to me that this is not a requirement for VACUUM or
> CLUSTER. That's all.
adding any significant overhead. All you need to do is something
like:
foo->changecount++;
pg_write_barrier();
foo->count_of_blocks++;
pg_write_barrier();
foo->changecount++;
I suspect that's plenty cheap enough to do for every block.
Вложения
В списке pgsql-hackers по дате отправления: