Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vch3d-0007A1-0i for pgsql-performance@arkaria.postgresql.org; Sat, 02 Nov 2013 19:40:29 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vch3c-0003vT-Be for pgsql-performance@arkaria.postgresql.org; Sat, 02 Nov 2013 19:40:28 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vch3b-0003vN-FP for pgsql-performance@postgresql.org; Sat, 02 Nov 2013 19:40:27 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vch3Y-0001UV-Rt for pgsql-performance@postgresql.org; Sat, 02 Nov 2013 19:40:26 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 2107A508C45 for ; Sat, 2 Nov 2013 20:40:24 +0100 (CET) X-Virus-Scanned: G-Hosting.cz + Station.cz + Klenot.cz + Subreg.cz amavisd-new at antispam.gransy.com Received: from mail.gransy.com ([82.208.44.189]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id WQXg1a4if-4L for ; Sat, 2 Nov 2013 20:40:35 +0100 (CET) Received: by mail.gransy.com (Postfix, from userid 5000) id EC1B6508C49; Sat, 2 Nov 2013 20:40:23 +0100 (CET) Received: from [192.168.1.227] (ip-78-45-139-138.net.upcbroadband.cz [78.45.139.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id BF294508C45 for ; Sat, 2 Nov 2013 20:40:23 +0100 (CET) Message-ID: <52755527.7000902@fuzzy.cz> Date: Sat, 02 Nov 2013 20:40:23 +0100 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Hot Standby performance issue References: <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> <1382736171070-5775972.post@n5.nabble.com> <526BCEBA.3010102@fuzzy.cz> <1382991814055-5776156.post@n5.nabble.com> In-Reply-To: <1382991814055-5776156.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 28.10.2013 21:23, sparikh wrote: > Hi, > > Yes, you are right. The table is the biggest one . Please find below the > information you requested. I agree the fact that autovacuum ran on this > table would fix the performance issue on standby does not sound very > convincing. But that is the only thing I could correlate when the query on > standby started working again. Otherwise there is absolutely no changes at > code level , database level or OS level. > As of now query is still working fine on standby. > > I may be wrong, but could it be the case that standby disk was too much > fragmented compare to primary and autovaccum on primary fixed that. > (Assuming autovacuum on primary internally triggers the same on standby) I find it very unlikely, but you didn't gave us necessary data (say, how much free space was on the disks, etc.). The best way to pinpoint the issue would be to run some profiler (which we have repeatedly asked you to do), but now that the issue disappeared we can only guess. Please monitor the system and if it happens again run perf or other profiler so that we know where the time is spent. Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance