Date: Fri, 25 Oct 2013 14:22:51 -0700 (PDT)
From: ramistuni <ramistuni@yahoo.com>
To: pgsql-performance@postgresql.org
Message-ID: <1382736171070-5775972.post@n5.nabble.com>
In-Reply-To: <1382491400068-5775550.post@n5.nabble.com>
References: <52658780.1040002@fuzzy.cz>
 <1382390332002-5775332.post@n5.nabble.com> <5265A28E.4060601@fuzzy.cz>
 <1382396377294-5775349.post@n5.nabble.com> <5265B562.3040407@fuzzy.cz>
 <1382400045239-5775361.post@n5.nabble.com> <5266BD42.2030303@fuzzy.cz>
 <1382478627757-5775529.post@n5.nabble.com> <52670702.3030201@fuzzy.cz>
 <1382491400068-5775550.post@n5.nabble.com>
Subject: Re: Hot Standby performance issue
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Today morning I found that the performance issue on standby database was
fixed by itself. On further investigation I found that one of the biggest 
used in this query had autovacuum  kicked in yesterday on primary. The last
time it had autovaccum ran was on Sep 30th.

I am suspecting that this should have been fixed the issue. The table has
update and delete operations. Only thing I did not understand why postgres
did not pick this table for autovacuum all these days, in spite of this
table is one of the busiest table from DML perspective. I was monitoring the
primary database activity all these days and always could see autovacuum was
running on another tables.

Thanks.


--
View this message in context: http://postgresql.1045698.n5.nabble.com/Hot-Standby-performance-issue-tp5774673p5775972.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance