Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1d7x-0005ca-R8 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 20:26:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h1d7v-0000Qg-HY for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 20:26:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1d7v-0000QZ-AO for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 20:26:55 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1d7s-000656-Td for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 20:26:54 +0000 Received: by mail-wr1-x443.google.com with SMTP id w2so14894661wrt.11 for ; Wed, 06 Mar 2019 12:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pV/abTfT7L8Em47Cn+3HgF9DUswd4H7/9s02oNaHwBk=; b=nyFLuDmsZmjEVdA8+pIowwDjC2vxZiFkiCfPxKr0Ww8PMWs178jsO/NXu3zDfORHqQ HHyOe7vKyArbCCbU2mqGMH0Zm2I3Df8KpNni1gSKpPGLk5zR6NEN++NYZ7umhVwZwHXm WcYUL5RdLRYYIjH2K8NKzBewaHnKjUcieDtow5Po6ziZysrZ6cR2101YH4MrPKDOr8X+ 9HVmqFfNEDryszRbccFv2VNGInjpl2toiU5aCvgJP4yt1Rp83FpCMUlMXUBkLetohLn4 k8Jw1+hlN+8/BWwnlYEzF97kQfUkr8k5X3wx9OcNiVLl8j1ochilRPSXuqGbEVfyBTQs gk1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pV/abTfT7L8Em47Cn+3HgF9DUswd4H7/9s02oNaHwBk=; b=bS2c+HRPOnHxqECfkwaMatPZj60qxgPuFItuLZUJJ47oaoCgyTqw/NjNqKhfEbExar eLk2YjfGAynC8HT5LXLh/rkZNE72fc9Uc56jnle7KFonlWe8bUesGPyHZ/BrLIkyvcq6 qs8rmTSL+yj+FAQF0HnE/v5nXEf4e+UKymiJhZhs8PPJw8huMGA/UVFPiX2Y3L8wlCOz NSYC76H4SJJeMX7MWAlXeM400DIXXDoJJmRvyBAqhLE1QtyEJOX4W9Ls3Dz2KlgZxAiZ szk4Shw2MIRXlNrw9Z7HHAlsC9S1W6Dw8UDC72FRVUtrr5OkrKE2CTxHnshIXl3jAD3k vCog== X-Gm-Message-State: APjAAAVK4GFyHxv6wqdMzuWjwUqMCF/pQC2lt6CepgCoX45+IB39OkUF r5mOhfiW7/6Tk3ZPEL3+41tWUh/RDILQNNfEgZG+WymE6CLgPGIsjCWWzKC566nI9gb8OLLIKhX pl31V+/tCe5sPuyWlwUFpvA69vvgLLeOV/dpU4RKxIzonIov3ZcfE+JfmNTMI8dI36Q2TIFXbpn MAhTqYThgaQb67DXUNol72lA== X-Google-Smtp-Source: APXvYqzIqFS/BfyoS2d3KG73CBao+HZCGKcE05PDHly0QLPLrUO8oVug0MV9bpdbTTSTPSG67YFFqw== X-Received: by 2002:adf:ecc6:: with SMTP id s6mr4367016wro.144.1551904011113; Wed, 06 Mar 2019 12:26:51 -0800 (PST) Received: from [10.137.0.17] (ip-86-49-253-144.net.upcbroadband.cz. [86.49.253.144]) by smtp.gmail.com with ESMTPSA id t69sm5430515wmt.16.2019.03.06.12.26.50 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 12:26:50 -0800 (PST) Subject: Re: Should we increase the default vacuum_cost_limit? To: David Rowley Cc: Peter Geoghegan , Robert Haas , Joe Conway , PostgreSQL Hackers References: <241b80ab-7af0-c606-7b2c-b0a5d6be696a@joeconway.com> From: Tomas Vondra Message-ID: <973536be-26a8-5857-430d-07cda99ee5b4@2ndquadrant.com> Date: Wed, 6 Mar 2019 21:26:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 3/6/19 12:10 AM, David Rowley wrote: > Thanks for chipping in on this. > > On Wed, 6 Mar 2019 at 01:53, Tomas Vondra wrote: >> But on the other hand it feels a bit weird that we increase this one >> value and leave all the other (also very conservative) defaults alone. > > Which others did you have in mind? Like work_mem, shared_buffers? If > so, I mentioned in the initial post that I don't see vacuum_cost_limit > as in the same category as those. It's not like PostgreSQL won't > start on a tiny server if vacuum_cost_limit is too high, but you will > have issues with too big a shared_buffers, for example. I think if > we insist that this patch is a review of all the "how big is your > server" GUCs then that's raising the bar significantly and > unnecessarily for what I'm proposing here. > On second thought, I think you're right. It's still true that you need to bump up various other GUCs on reasonably current hardware, but it's true vacuum_cost_limit is special enough to increase it separately. so +1 (I see Andrew already pushed it, but anyway ...) -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services