Message-ID: <534BEF32.9060309@cs.utoronto.ca>
Date: Mon, 14 Apr 2014 10:22:42 -0400
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Kevin Grittner <kgrittn@ymail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: SSI slows down over time
References: <1397484864.73109.YahooMailBasic@web122302.mail.ne1.yahoo.com>
In-Reply-To: <1397484864.73109.YahooMailBasic@web122302.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 14/04/2014 10:14 AM, Kevin Grittner wrote:
> Ryan Johnson <ryan.johnson@cs.utoronto.ca> wrote:
>
>> every time I shut down a database and bring it back up, SSI seems
>> to go slower.
> There's one thing to rule out up front -- that would be a
> long-lived prepared transaction.
>
> Please post the output of these queries:
>
> select version();
> show max_prepared_transactions;
> select * from pg_prepared_xacts;
Hmm. My machine was rebooted over the weekend for Heartbleed patches, so 
I'll have to re-build the database and fire off enough runs to repro. 
There are some disadvantages to keeping it in tmpfs...

Meanwhile, a quick question: what factors might cause a prepared 
transaction to exist in the first place? I'm running a single-node db, 
and I've had only normal database shutdowns, so I wouldn't have expected 
any.

Thoughts?
Ryan


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