Re: Table-level log_autovacuum_min_duration - Mailing list pgsql-hackers

From Naoya Anzai
Subject Re: Table-level log_autovacuum_min_duration
Date
Msg-id 20150206003956.26067.81714.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Re: Table-level log_autovacuum_min_duration  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Table-level log_autovacuum_min_duration  (Naoya Anzai <anzai-naoya@mxu.nes.nec.co.jp>)
Re: Table-level log_autovacuum_min_duration  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world:  tested, failed
Implements feature:       tested, failed
Spec compliant:           tested, failed
Documentation:            tested, failed

Hi,

I'm Naoya Anzai.
I've been working as a PostgreSQL Support Engineer for 6 years.
I am a newcomer of reviewing, and My programming skill is not so high.
But the following members also participate in this review. (We say 
"Two heads are better than one." :))

Akira Kurosawa <kurosawa-akira@mxc.nes.nec.co.jp>
Taiki Kondo <kondo-taiki@mxt.nes.nec.co.jp>
Huong Dangminh <dangminh-huong@mxm.nes.nec.co.jp>

So I believe reviewing patches is not difficult for us.

This is a review of Table-level log_autovacuum_min_duration patch:
http://www.postgresql.org/message-id/CAB7nPqTBQsbEgvb8cOH01K7ARGYs9KBuV8dr+aqGonFVb8koAQ@mail.gmail.com

Submission review
====================
The patch applies cleanly to HEAD, and it works fine on Fedora 
release 20.
There is no regression test,but I think it is no problem 
because other parameter also is not tested.


Usability review
====================
pg_dump/pg_restore support is OK.
I think this feature is a nice idea and I also want this feature.


Feature test
====================
I executed following commands after setting 
"log_autovacuum_min_duration" to 1000 in the GUC. ("bar" table is 
already created with no options.)
CREATE TABLE foo ( ... ) WITH ( log_autovacuum_min_duration = 0 );ALTER TABLE bar SET (log_autovacuum_min_duration = 0
);

Then, only in "foo" and "bar" table, autovacuum log was printed out 
even if elapsed time of autovacuum is lesser than 1000ms. This 
behavior was expected and there was no crash or failed assertion. 
So it looked good for me. But, I executed following command, in 
"buzz" table, autovacuum log was printed out if elapsed time is 
more than 1000ms.
CREATE TABLE buzz ( ... ) WITH ( log_autovacuum_min_duration = -1 );
          ^^
 

I expect autovacuum log is NOT printed out even if elapsed time is 
more than 1000ms in this case. My thought is wrong, isn't it? In my 
opinion, there is an use case that autovacuum log is always printed 
out in all tables excepting specified tables. I think there is a 
person who wants to use it like this case, but I (or he) can NOT use 
in this situation.

How about your opinion?


Performance review
====================
Not reviewed from this point of view.


Coding review
====================
I think description of log_autovacuum_min_duration in reloptions.c
(line:215) should be like other parameters (match with guc.c). So 
it should be "Sets the minimum execution time above which autovacuum 
actions will be logged." but not "Log autovacuum execution for 
given threshold".

There is no new function which is defined in this patch, and 
modified contents are not related to OS-dependent contents, so I 
think it will work fine on Windows/BSD etc.


Architecture review
====================
About the modification of gram.y.

I think it is not good that log_min_duration is initialized to 
zeros in gram.y when "FREEZE" option is set. Because any VACUUM 
queries never use this parameter. I think log_min_duration always 
should be initialized to -1.


Regards,
Naoya Anzai (NEC Solution Innovators,Ltd.)


The new status of this patch is: Waiting on Author



pgsql-hackers by date:

Previous
From: Dan Langille
Date:
Subject: HEADS UP: PGCon 2015 major schedule changes
Next
From: Amit Langote
Date:
Subject: RangeType internal use