Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZL2BX-0003xn-9p for pgsql-admin@arkaria.postgresql.org; Fri, 31 Jul 2015 04:44:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZL2BW-0002fL-HY for pgsql-admin@arkaria.postgresql.org; Fri, 31 Jul 2015 04:44:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZL2BU-0002f1-39 for pgsql-admin@postgresql.org; Fri, 31 Jul 2015 04:44:42 +0000 Received: from nm1-vm7.bullet.mail.sg3.yahoo.com ([106.10.148.78]) by magus.postgresql.org with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZL2BP-00024S-I0 for pgsql-admin@postgresql.org; Fri, 31 Jul 2015 04:44:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s2048; t=1438317867; bh=Xw6oPvSn2zBubktWHbkLwYCzCGtvMAFYGfN4ILd7et0=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=ExrVtGPU5QcTMwiNp+kOxLzvNo6szYyFO/XaOuUWJTB7nJpjnFdVW7WcJcXnhTbUpqXb7sKVMNLp1thRMr3WhvYygdhpeCfGY1FZSeKAk1X8HJjKUzBTaX1mYR6jeOtgpiH00njUL8/IuhpTnT1pbQfCFUQdZ93OBbfU0YQ+yPL4b9GcP1HIX/61bfz7BdiRkZjOSrnZEfUx0onPZadYbbRFmuVmloFR7Uc81BmNuDlKyFFxwb4kUOvSSXNolfffepSQP63ZB+YRYz+o3/gnn8GH2mO6z0jzPpcdhcnRdOQI6d72UM+lwvJz4sJK6C4LeUqAVwu8mSFr/VQOwlSVFw== Received: from [106.10.166.63] by nm1.bullet.mail.sg3.yahoo.com with NNFMP; 31 Jul 2015 04:44:27 -0000 Received: from [106.10.151.122] by tm20.bullet.mail.sg3.yahoo.com with NNFMP; 31 Jul 2015 04:44:27 -0000 Received: from [127.0.0.1] by omp1004.mail.sg3.yahoo.com with NNFMP; 31 Jul 2015 04:44:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 801977.72604.bm@omp1004.mail.sg3.yahoo.com X-YMail-OSG: hCzZhlkVM1n8ncpq1plkpZDlCWPEV8suX5IGtCI1.iQ0e8A7eWuwJ_qYihbGScs 3q.kK4u6Dm_2COw2Hd2UnglXGNYMLg0dYcZViFk4A1CU5PFQ.K6f3EjNPun3UPOAVVkiIVPtJvV7 XH7oC0d6sl5RioGm9VqQeoq8PlCPT1udqRLun45.K25ozw.Th2ep4vUJwZaMf1WwLQC8Rod0J5fu lto7lWfvot.i9ZlOr6ZS7GcixzRHWSuMbWqZqU6uw1z2DJNlSrye5ffOPX8gEE8nWmfd2I9BEXcx d13zZhVWuk0lIka2Zfy7ely8OFuOMvouH2mrz_qkxSXzjb_a2w.ztrELW_lHnRWCMkwsoNoe1ei_ Ld2QvUQu8zWT8jDQ57EumXajUH20A3zjnIe74X6UqpowbxcuDM0q5c.wszcxC8v4Fk3peUd74wan Z2MSMHTT6F_DCps4kqcw1zlzFTWL.AzaCt4uvs0uip.tHzgeSjt8Gm9055xYHJnC8EPvaNTXmzK. fDqVDgQ-- Received: by 106.10.196.176; Fri, 31 Jul 2015 04:44:27 +0000 Date: Fri, 31 Jul 2015 04:44:27 +0000 (UTC) From: Om Prakash Jaiswal Reply-To: Om Prakash Jaiswal To: John Scalia , "pgsql-admin@postgresql.org" Message-ID: <810264764.37549.1438317867083.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Autovacuum behavior MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37548_1118458198.1438317867078" Content-Length: 4018 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org ------=_Part_37548_1118458198.1438317867078 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable track_count =3D on;It is missing. RegardsOm Prakash=20 On Friday, 31 July 2015 12:21 AM, John Scalia = wrote: =20 Hi all, The autovacuum settings for a 9.4.2 database are shown below, I'm not absol= utely certain if I missed anything: autovacuum =3D onlog_autovacuum_min_duration =3D 100autovacuum_max_workers = =3D 15autovacuum_naptime =3D 10min#autovacuum_vacuum_threshold =3D 50autova= cuum_analyze_threshold =3D 80autovacuum_vacuum_scale_factor =3D 0.1autovacu= um_analyze_scale_factor =3D 0.2autovacuum_freeze_max_age =3D 100000000autov= acuum_vacuum_cost_delay =3D 20msautovacuum_vacuum_cost_limit =3D -1vacuum_f= reeze_min_age =3D =C2=A0 5000000vacuum_freeze_table_age =3D 2500000 But, when I examine pg_stat_all_tables, I'm seeing a lot of tables where n_= dead_tup is still a lot greater than n_live_tup. Mind you, these are all fa= irly small tables. I'm also seeing that the last_autovacuum ran about 11:22= AM CDT this morning.I would think the tables where there were no live tupl= es and a bunch of dead_tuples would have been vacuumed after 11:22 AM to cl= ear the dead ones. Am I missing something?--Jay ------=_Part_37548_1118458198.1438317867078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
trac= k_count =3D on;
It is missing.
Rega= rds
Om Prakash



On Friday, 31 July 2015 12:21 AM, John Scalia <jayknowsunix@gmail.co= m> wrote:


Hi all,

The aut= ovacuum settings for a 9.4.2 database are shown below, I'm not absolutely c= ertain if I missed anything:

autovacuum =3D o= n
log_autovacuum_min_duration =3D 100
autovacuum_max_wo= rkers =3D 15
autovacuum_naptime =3D 10min
#autovacuum_v= acuum_threshold =3D 50
autovacuum_analyze_threshold =3D 80
<= div>autovacuum_vacuum_scale_factor =3D 0.1
autovacuum_analyze_sca= le_factor =3D 0.2
autovacuum_freeze_max_age =3D 100000000
autovacuum_vacuum_cost_delay =3D 20ms
autovacuum_vacuum_cost_l= imit =3D -1
vacuum_freeze_min_age =3D   5000000
vacuum_freeze_table_age =3D 2500000


But, when I examine pg_stat_all_tables, I'm seeing a lot of= tables where n_dead_tup is still a lot greater than n_live_tup. Mind you, = these are all fairly small tables. I'm also seeing that the last_autovacuum= ran about 11:22 AM CDT this morning.I would think the tables where there w= ere no live tuples and a bunch of dead_tuples would have been vacuumed afte= r 11:22 AM to clear the dead ones. Am I missing something?
--
Jay


------=_Part_37548_1118458198.1438317867078--