pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: sparikh <sparikh@ecotality.com>
To: pgsql-performance@postgresql.org
Subject: Re: Hot Standby performance issue
Date: Mon, 28 Oct 2013 13:23:34 -0700 (PDT)
Message-ID: <1382991814055-5776156.post@n5.nabble.com> (raw)
In-Reply-To: <526BCEBA.3010102@fuzzy.cz>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

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)


Sequential Scans	18	
Sequential Tuples Read	1355777067	
Index Scans	102566124	
Index Tuples Fetched	67155748	
Tuples Inserted	16579520	
Tuples Updated	17144291	
Tuples Deleted	24383607	
Tuples HOT Updated	1214531	
Live Tuples	101712125	
Dead Tuples	3333207	
Heap Blocks Read	420703920	
Heap Blocks Hit	496135814	
Index Blocks Read	66807468	
Index Blocks Hit	916783267	
Toast Blocks Read	310677	
Toast Blocks Hit	557735	
Toast Index Blocks Read	6959	
Toast Index Blocks Hit	936473	
Last Vacuum		
Last Autovacuum	2013-10-25 02:47:09.914775-04	
Last Analyze		
Last Autoanalyze	2013-10-25 18:39:25.386091-04	
Vacuum counter	0	
Autovacuum counter	2	
Analyze counter	0	
Autoanalyze counter	4	
Table Size	46 GB	
Toast Table Size	615 MB	
Indexes Size	20 GB



--
View this message in context: http://postgresql.1045698.n5.nabble.com/Hot-Standby-performance-issue-tp5774673p5776156.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



view thread (31+ messages)  latest in thread

Message-ID: <1382991814055-5776156.post@n5.nabble.com>
Permalink:  ../1382991814055-5776156.post@n5.nabble.com/
Also on:    postgresql.org/message-id/1382991814055-5776156.post@n5.nabble.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sparikh@ecotality.com
  Subject: Re: Hot Standby performance issue
  In-Reply-To: <1382991814055-5776156.post@n5.nabble.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox