Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYgG5-0005xq-GG for pgsql-performance@arkaria.postgresql.org; Tue, 22 Oct 2013 18:00:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VYgG4-0001lY-W1 for pgsql-performance@arkaria.postgresql.org; Tue, 22 Oct 2013 18:00:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYgG4-0001lS-8M for pgsql-performance@postgresql.org; Tue, 22 Oct 2013 18:00:44 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VYgFx-0005HC-LY for pgsql-performance@postgresql.org; Tue, 22 Oct 2013 18:00:43 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 3D076508C5D for ; Tue, 22 Oct 2013 20:00:35 +0200 (CEST) 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 X9nMqUj1bGM8 for ; Tue, 22 Oct 2013 20:00:46 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 12EAF508C61; Tue, 22 Oct 2013 20:00:35 +0200 (CEST) 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 D76AD508C5D for ; Tue, 22 Oct 2013 20:00:34 +0200 (CEST) Message-ID: <5266BD42.2030303@fuzzy.cz> Date: Tue, 22 Oct 2013 20:00:34 +0200 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: <1381869626548-5774673.post@n5.nabble.com> <1382291901534-5775181.post@n5.nabble.com> <526460B7.3020008@fuzzy.cz> <1382367933794-5775257.post@n5.nabble.com> <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> In-Reply-To: <1382400045239-5775361.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 22.10.2013 02:00, sparikh wrote: >> Do you suggest if I remove all the data files from /data/base folder >> of standby and again rebuild using rsync from primary ? do you see >> any issues there.? This is just to rule out any fragmentation on >> standby side. > > The EXPLAIN really should not do much I/O. I doubt it has anything to do > with fragmentation, so I doubt this is going to help. > > Actually I was referring to this in the context of addressing main > underlying performance issue, not EXPLAIN. Sorry, I may not have > communicated it correctly. > > Even strance does not seem to be installed. It's 'strace' (aka syscall trace), not 'strance'. Please install both perf and strace and try to collect some information about the backend executing the slow query. We're mostly speculating and we need the data. Try perf first - it's basically a profiler and the results are usually understandable. Even a simple "perf top" can give us a hint. Strace is much more low-level and much more difficult to analyze. > The filesytem type it shows to me ext3. OK. Not the best filesystem IMHO, but I doubt it's related to the issue we're discussing here. Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance