Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UzrnC-0006H1-OU for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jul 2013 17:15:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UzrnB-0004Ec-JP for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jul 2013 17:15:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Uzrn9-0004EQ-3W for pgsql-hackers@postgresql.org; Thu, 18 Jul 2013 17:14:59 +0000 Received: from moutng.kundenserver.de ([212.227.126.171]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Uzrn6-0000hI-78 for pgsql-hackers@postgresql.org; Thu, 18 Jul 2013 17:14:58 +0000 Received: from [192.168.1.110] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LlrKG-1UQo1J1feq-00Zcyc; Thu, 18 Jul 2013 19:14:50 +0200 Message-ID: <51E82288.8080502@2ndQuadrant.com> Date: Thu, 18 Jul 2013 13:14:48 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alvaro Herrera CC: Robert Haas , Heikki Linnakangas , KONDO Mitsumasa , PostgreSQL-development Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses References: <51BDCB6C.1090507@vmware.com> <51BEB6F5.7070907@lab.ntt.co.jp> <51C40EF4.1080201@lab.ntt.co.jp> <51C9D03B.10107@vmware.com> <51C9FD5C.5050706@vmware.com> <51E2F865.8030406@2ndQuadrant.com> <51E80CBC.10204@2ndQuadrant.com> <20130718160045.GN4165@eldon.alvh.no-ip.org> In-Reply-To: <20130718160045.GN4165@eldon.alvh.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:00sGtRmHNuSnf5UQbNT6M8dvJ0ocqWOhfXPBDlyaRFr 8dSNfReQUDk/P/qrt0e2HKroUdAkl/Uw+hx1YwYlGbR7ZPV4/F oxhF3IGjJyz04npYbHa9d9QJwSzHuuUew5s3ZrOghRNFebHlH4 3zTsPjQnIA1V5XS+IMoIaNGpwITCitSN+Mul3pKRczRdaECZJH iX+JRcllUuhcURQ/XINOgm7z8voh9PvscufiJP3UIsdNyM439S YduGoPM1/P3lRxa9j2M4HOMxJYPYRgPale+ENCzlw7djT5cj2P b7vIACgqeXIjsWXTnlr+3jQW3dAaK+U6EkrW+i8ntHlKIvLhfG b8vFDMRBxrclpEARtc7c= X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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