Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UzqdU-0002iL-Be for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jul 2013 16:00:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UzqdT-0001kw-Pr for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jul 2013 16:00:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UzqdR-0001ix-KW for pgsql-hackers@postgresql.org; Thu, 18 Jul 2013 16:00:53 +0000 Received: from smtprelay0075.b.hostedemail.com ([64.98.42.75] helo=smtprelay.b.hostedemail.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UzqdN-0007oO-UW for pgsql-hackers@postgresql.org; Thu, 18 Jul 2013 16:00:53 +0000 Received: from filter.hostedemail.com (b-bigip1 [10.5.19.254]) by smtprelay04.b.hostedemail.com (Postfix) with ESMTP id 40FF57B85E; Thu, 18 Jul 2013 16:00:48 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Panda: scanned! X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, alvherre@alvh.no-ip.org, :::::::::, RULES_HIT:355:379:599:967:973:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2198:2199:2393:2525:2560:2563:2682:2685:2693:2828:2859:2906:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4605:4659:5007:6261:7903:9025:9121:10004:10400:10450:10455:10848:11232:11256:11257:11658:11914:12296:12517:12519:12740:13069:13146:13230:13255:13311:13357:13894:13895:19904:19999, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0 X-HE-Tag: bed14_24043c4e5ac54 X-Filterd-Recvd-Size: 2955 Received: from eldon.alvh.no-ip.org (unknown [190.95.9.207]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf06.b.hostedemail.com (Postfix) with ESMTPA; Thu, 18 Jul 2013 16:00:47 +0000 (UTC) Received: by eldon.alvh.no-ip.org (Postfix, from userid 1000) id C36DD1FC5; Thu, 18 Jul 2013 12:00:45 -0400 (CLT) Date: Thu, 18 Jul 2013 12:00:45 -0400 From: Alvaro Herrera To: Greg Smith Cc: Robert Haas , Heikki Linnakangas , KONDO Mitsumasa , PostgreSQL-development Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses Message-ID: <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> <51C9FD5C.5050706@vmware.com> <51E2F865.8030406@2ndQuadrant.com> <51E80CBC.10204@2ndQuadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51E80CBC.10204@2ndQuadrant.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Greg Smith escribió: > On 7/18/13 11:04 AM, Robert Haas wrote: > >On a system where fsync is sometimes very very slow, that > >might result in the checkpoint overrunning its time budget - but SO > >WHAT? > > Checkpoints provide a boundary on recovery time. That is their only > purpose. You can always do better by postponing them, but you've > now changed the agreement with the user about how long recovery > might take. > > And if you don't respect the checkpoint boundary, what you can't do > is then claim better execution performance than something that did. > It's always possible to improvement throughput by postponing I/O. > SO WHAT? If that's OK, you don't need complicated logic to do that. > Increase checkpoint_timeout. The system with checkpoint_timeout at > 6 minutes will always outperform one where it's 5. 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. In any case, if the system crashes past minute 5 after the previous checkpoint (the worst possible timing), the current checkpoint will have already started, so recovery will take slightly less time because some flush work had already been done. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers