Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3sgo-0008I1-I5 for pgsql-general@arkaria.postgresql.org; Thu, 27 Apr 2017 23:19:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d3sgo-00038E-2J for pgsql-general@arkaria.postgresql.org; Thu, 27 Apr 2017 23:19:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d3sgm-000370-Ik for pgsql-general@postgresql.org; Thu, 27 Apr 2017 23:19:08 +0000 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d3sgi-0004TB-Li for pgsql-general@postgresql.org; Thu, 27 Apr 2017 23:19:07 +0000 Received: by mail-wm0-x22e.google.com with SMTP id u65so29044306wmu.1 for ; Thu, 27 Apr 2017 16:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FDsJstqbFTcQFLJSCRVzLtiXAdck6cQHi0N7SOEDxsE=; b=UUln5iiO8tE9VlC8cxsaLhr8hidzZxUinTe8CWGW1rBvwmTtZdd0TPqdoSIR88Qw7c x6yGFKzmvsI7rcBV+XrP9A2u08Nyumec6A0pc8LfAyoja9ah2WY9l9DivFa+o5JNGweZ fQoDZtMoRTlU0oLc7rkpXXY96frwANXkcC8kKyTVwgcxMm3oeoi32/ZQxdiOuVC8xMVq eUb2APKqANruOw/JqU3I2Qf/ByQZ5cCRaW2poR5IeVAFlJf09Hu9NHxOvf15kG8Ccy5h rRu7ktZIKbsam3tKRIBvgxOKb2aFyW9dBbXkxKzS3ZZR8BicaFS52e1PaXNNnmsQKeIj zlfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FDsJstqbFTcQFLJSCRVzLtiXAdck6cQHi0N7SOEDxsE=; b=HjkofyHx1ttwEDbvxEDbMwGOHERaVnfxLP/yKv/G5GHKEUbvi4HBQNjn6E51yZtULQ 10TaDlExrNgJ/t85mr2A3N4S7F29CdKs1tU9H2A/5I3bfd5YBCfdeqRr8c58p1EZBc6F AgBqT5MR6AAuEVzw9/R+0LuL4gcmsf/l+K16HXiMVMRCL+rWv9XNtWyzXBgpbEey62+m xfa6k2lEZ/CYLAgpZRCdzIsHbyu6dr6FzDECUN6gtJTtSWyqqL4X297FY+MpAa4Rqd+n iHcwSyPus1Y1W6Kv29ZV+H45chCdU5be0SMiMY4FBOXc7lfy5IQOIYXh41s7QqWyXvId jQkg== X-Gm-Message-State: AN3rC/7ge0SmNPeBUA0j9uHQxPW8LG17j27YEVykxl0P6R9eRvcQTFVO +MDOvMpj86MO7T9tMRZueQ== X-Received: by 10.28.11.207 with SMTP id 198mr4251955wml.38.1493335142386; Thu, 27 Apr 2017 16:19:02 -0700 (PDT) Received: from [10.137.2.17] (ip-89-177-46-65.net.upcbroadband.cz. [89.177.46.65]) by smtp.gmail.com with ESMTPSA id m201sm6564514wmd.15.2017.04.27.16.19.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 16:19:01 -0700 (PDT) Subject: Re: [PERFORM] Questionaire: Common WAL write rates on busy servers. To: Andres Freund , "Joshua D. Drake" References: <20170425041743.ddabv2mwevcmtx5a@alap3.anarazel.de> <20170427155906.uudovtd62x56brmx@alap3.anarazel.de> <20170427163407.dtqi6v57bj4tiu5c@alap3.anarazel.de> Cc: pgsql-general@postgresql.org, pgsql-performance@postgresql.org From: Tomas Vondra Message-ID: <8036f0b9-6bb9-d802-d301-53b488dea49f@2ndquadrant.com> Date: Fri, 28 Apr 2017 01:18:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170427163407.dtqi6v57bj4tiu5c@alap3.anarazel.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org On 04/27/2017 06:34 PM, Andres Freund wrote: > On 2017-04-27 09:31:34 -0700, Joshua D. Drake wrote: >> On 04/27/2017 08:59 AM, Andres Freund wrote: >> >>> >>> Ok, based on the, few, answers I've got so far, my experience is >>> indeed skewed. A number of the PG users I interacted with over >>> the last couple years had WAL write ranges somewhere in the range >>> of 500MB/s to 2.2GB/s (max I'veseen). At that point WAL insertion >>> became a major bottleneck, even if storage was more than fast >>> enough to keep up. To address these we'd need some changes, but >>> the feedback so far suggest that it's not yet a widespread >>> issue... >> >> I would agree it isn't yet a widespread issue. > > I'm not yet sure about that actually. I suspect a large percentage > of people with such workloads aren't lingering lots on the lists. > To a certain extent, this is a self-fulfilling prophecy. If you know you'll have such a busy system, you probably do some research and testing first, before choosing the database. If we don't perform well enough, you pick something else. Which removes the data point. Obviously, there are systems that start small and get busier and busier over time. And those are the ones we see. cheers -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general