Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 5FB81633C15 for ; Thu, 14 Jan 2010 14:31:14 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 45454-02 for ; Thu, 14 Jan 2010 18:31:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id D9AB1632601 for ; Thu, 14 Jan 2010 14:31:01 -0400 (AST) Received: from [192.168.1.3] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Mb5Ch-1NAnzI3lRT-00Kjgs; Thu, 14 Jan 2010 19:30:51 +0100 Message-ID: <4B4F62D6.7020104@2ndquadrant.com> Date: Thu, 14 Jan 2010 13:30:46 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Colson CC: Craig Ringer , pgsql-performance@postgresql.org Subject: Re: a heavy duty operation on an "unused" table kills my server References: <4B4D5698.8040808@emolecules.com> <4B4D61DA.7080008@postnewspapers.com.au> <603c8f071001130823l69804fe3m5c6fbb081c55c265@mail.gmail.com> <4B4EAD76.9030305@postnewspapers.com.au> <4B4F2F00.7070401@squeakycode.net> <4B4F5D70.4020103@2ndquadrant.com> <4B4F5F45.105@squeakycode.net> In-Reply-To: <4B4F5F45.105@squeakycode.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/pESwa74A8zWb0aMfOz44gs2wr7I21Pov5qBn RP2jVLLl3N4e78VXBmYP0BjIQ5oiD5twhC+F0XeF5YPkUXV1RS cvFVgOBfvDtTEsANOP6rFCcMHbwPpOD X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.426 tagged_above=-10 required=5 tests=AWL=0.173, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201001/297 X-Sequence-Number: 37177 Andy Colson wrote: > So if there is very little io, or if there is way way too much, then > the scheduler really doesn't matter. So there is a slim middle ground > where the io is within a small percent of the HD capacity where the > scheduler might make a difference? That's basically how I see it. There seem to be people who run into workloads in the middle ground where the scheduler makes a world of difference. I've never seen one myself, and suspect that some of the reports of deadline being a big improvement just relate to some buginess in the default CFQ implementation that I just haven't encountered. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com