pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <greg@2ndQuadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Date: Thu, 18 Jul 2013 13:14:48 -0400
Message-ID: <51E82288.8080502@2ndQuadrant.com> (raw)
In-Reply-To: <20130718160045.GN4165@eldon.alvh.no-ip.org>
References: <51BDCB6C.1090507@vmware.com>
	<51BEB6F5.7070907@lab.ntt.co.jp>
	<51C40EF4.1080201@lab.ntt.co.jp>
	<51C9D03B.10107@vmware.com>
	<CA+TgmoZ+ofyg4e+hRBTnnfrC7M2ATX-Pg0k4AtyHx60A+_DFhQ@mail.gmail.com>
	<51C9FD5C.5050706@vmware.com>
	<CA+TgmoZj-0CFLbjceMtgi1t_=hpfe9z8uSa+D0g77sNYcFy04w@mail.gmail.com>
	<51E2F865.8030406@2ndQuadrant.com>
	<CA+TgmoY=GTANT6uNV4Ds6H6K0sRuWxSHErOaHSVDLvMPxYwqDA@mail.gmail.com>
	<51E80CBC.10204@2ndQuadrant.com>
	<20130718160045.GN4165@eldon.alvh.no-ip.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 7/18/13 12:00 PM, Alvaro Herrera wrote:
> I think the idea is to have a system in which most of the time the
> recovery time will be that for checkpoint_timeout=5, but in those
> (hopefully rare) cases where checkpoints take a bit longer, the recovery
> time will be that for checkpoint_timeout=6.

I understand the implementation.  My point is that if you do that, the 
fair comparison is to benchmark it against a current system where 
checkpoint_timeout=6 minutes.  That is a) simpler, b) requires no code 
change, and c) makes the looser standards the server is now settling for 
transparent to the administrator.  Also, my expectation is that it would 
perform better all of the time, not just during the periods this new 
behavior kicks in.

Right now we have checkpoint_completion_target as a GUC for controlling 
what's called the spread of a checkpoint over time.  That sometimes goes 
over, but that's happening against the best attempts of the server to do 
better.

The first word that comes to mind for for just disregarding the end time 
is that it's a sloppy checkpoint.  There is all sorts of sloppy behavior 
you might do here, but I've worked under the assumption that ignoring 
the contract with the administrator was frowned on by this project.  If 
people want this sort of behavior in the server, I'm satisfied my 
distaste for the idea and the reasoning behind it is clear now.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


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



view thread (63+ messages)  latest in thread

Message-ID: <51E82288.8080502@2ndQuadrant.com>
Permalink:  ../51E82288.8080502@2ndQuadrant.com/
Also on:    postgresql.org/message-id/51E82288.8080502@2ndQuadrant.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-hackers@postgresql.org
  Cc: greg@2ndQuadrant.com, alvherre@2ndquadrant.com, robertmhaas@gmail.com, hlinnakangas@vmware.com, kondo.mitsumasa@lab.ntt.co.jp
  Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
  In-Reply-To: <51E82288.8080502@2ndQuadrant.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