Re: Table-level log_autovacuum_min_duration
От | Michael Paquier |
---|---|
Тема | Re: Table-level log_autovacuum_min_duration |
Дата | |
Msg-id | CAB7nPqQy0EU0XGtkhc1KhoKu1eP7hptCiVz63GMppwcuOd=LDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Table-level log_autovacuum_min_duration (Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp>) |
Ответы |
Re: Table-level log_autovacuum_min_duration
|
Список | pgsql-hackers |
On Fri, Feb 13, 2015 at 10:16 AM, Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp> wrote: >>> You mean that ... >>> Log_autovacuum_min_duration assumes a role of VACOPT_VERBOSE. >>> Even if this parameter never use currently for manual vacuum, >>> log_autovacuum_min_duration should be set zero(anytime output) >>> when we executes "VACUUM(or ANALYZE) VERBOSE". >>> Is my understanding correct? If so,it sounds logical. >>> >> >>Yup, that's my opinion. Now I don't know if people would mind to remove >>VACOPT_VERBOSE and replace the control it does by log_min_duration in >>VacuumStmt. At least both things are overlapping, and log_min_duration >>offers more options than the plain VACOPT_VERBOSE. > > OK. I agree with you. > Please re-implement as you are thinking. Thanks. Attached is an updated patch will all those things implemented. >>> If we can abolish VERBOSE option, >>> I think it's ideal that we will prepare a new parameter like >>> a log_min_duration_vacuum(and log_min_duration_analyze) which >>> integrating "VERBOSE feature" and "log_autovacuum_min_duration". >>> >> >>What I think you are proposing here is a VERBOSE option that hypothetically >>gets activated if a manual VACUUM takes more than a certain amount >>specified by those parameters. I doubt this would be useful. In any case >>this is unrelated to this patch. > > I suspect manual vacuum often executes as "semi-auto vacuum" > by job-scheduler, cron, etc in actual maintenance cases. > Whether auto or manual, I think that's important to output > their logs in the same mechanism. > > Sorry, I seem to have wandered from the subject. This patch is a step in this direction as it enables any backend-side code to set up VacuumStmt with a custom timestamp value to output logs after a given timing, for example in background workers. For the client-side of things, I am unsure if we'd actually want it, we should always VERBOSE when this option is invoked through a query, and not add any hypothetical condition on it... Btw, after hacking on this it happens that we cannot completely remove VACOPT_VERBOSE as gram.y needs to take into account options with parenthesis :) But we can limit its use to the query parser only, similarly for VACOPT_FREEZE. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: