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.92) (envelope-from ) id 1jH8X6-0000gb-Li for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 16:05:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jH8X3-0006gG-Sl for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 16:05:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jH8X3-0006fC-GQ for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 16:05:29 +0000 Received: from mail-qv1-xf41.google.com ([2607:f8b0:4864:20::f41]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jH8X0-0000QJ-OW for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 16:05:28 +0000 Received: by mail-qv1-xf41.google.com with SMTP id m2so1297218qvu.13 for ; Wed, 25 Mar 2020 09:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WzhO89MgZMYxP1ThXD5LRHrzNwWdStQCxm3Z8GM2a+U=; b=XdBpw8B1PAqlhmbxYx79rlyv84S7nujCxYKjmDCg7BOzfdepVZeW2XSJAQZZOSC2cX RsYSb6L3OWoeY071HKZ9v3vDwuhkAhn+bJ4d1lyN9z8TH7Qv9bx3LSz5kfhws/KWsoVy AzeOqVSEVWxDDolZekdj7v2MiEls8keI7BidxMf+9HiMECs0ASbWq5B0v7BtoM1Q/NU/ gQ3abPJbEoRLxSUIyvL0gZcpwQrjMj5BjfB6hMnhOF62mqeVTDPD7ZgazRcpMj4Dv2Ku bdicyC/JVXLSj/t3vF3rq6xS599CAgWTJ0Kbin3UKffot5Ca8zt6wML7YE936YTTgLMW zY9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WzhO89MgZMYxP1ThXD5LRHrzNwWdStQCxm3Z8GM2a+U=; b=HGl3SGvMxg7zq3FFplck8KrdMdvY6mlv2IRbH8HGALXl11prUu1Tx3hH6htwjLdxHu ZUhxN9WVeeKGZmDjVDbRxDDAKH4GXrImCncFEOU0SLaiIvKLM1o/jk/TMZMs7v92NLQK bPysq8h/o8GBzRAAE3FBO4I8W17u9xm6Bd1A6uTH/eMfP+tlfirMICL7lSyCD3Si0hCc m6RTt1W/dYPMAkaiguVtY3w0mcUI6lalL2UTQYDAXVGEBhISm2GmeBW8Xsa95su1VkxL 5gNmfjKOuOHM9qZdFcjhP+qTMLFFWrmuc8Wyg2sG5PxDKkyo/CKXL17W7ZsRFaRBHPK7 Z6PA== X-Gm-Message-State: ANhLgQ094MHGhR8oNGo7JHKq2fraJ0e+Jr9rqKbZOxDnS5/3McJFOYwO mLBBGWPi0mg2lIY7wqZs1Iotjw== X-Google-Smtp-Source: ADFU+vvbwYr4iW1v77vzk/avFTkjpF3s+1Szq4h0Wxe1B4iWnzK2l6FaZduE20+Z2alRjMr6ng+sRA== X-Received: by 2002:a05:6214:11f4:: with SMTP id e20mr3906487qvu.66.1585152325028; Wed, 25 Mar 2020 09:05:25 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id w38sm6651646qth.68.2020.03.25.09.05.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 09:05:23 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 706DD800C28; Wed, 25 Mar 2020 11:05:21 -0500 (CDT) Date: Wed, 25 Mar 2020 11:05:21 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Laurenz Albe , Andres Freund , Masahiko Sawada , David Rowley , Tomas Vondra , Amit Kapila , Masahiko Sawada , Darafei =?utf-8?Q?Kom=D1=8Fpa?= Praliaskouski , pgsql-hackers@lists.postgresql.org, Michael Banck Subject: Re: Berserk Autovacuum (let's save next Mandrill) Message-ID: <20200325160521.GA21443@telsasoft.com> References: <20200325150656.GX21443@telsasoft.com> <20200325154652.GA13069@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200325154652.GA13069@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Mar 25, 2020 at 12:46:52PM -0300, Alvaro Herrera wrote: > On 2020-Mar-25, Justin Pryzby wrote: > > > Maybe in the docs you can write this with thousands separators: 10,000,000 > > > > It looks like the GUC uses scale factor max=1e10, but the relopt is still > > max=100, which means it's less possible to disable for a single rel. > > I have paid no attention to this thread, but how does it make sense to > have a scale factor to be higher than 100? Surely you mean the > threshold value that should be set to ten million, not the scale factor? We went over this here: https://www.postgresql.org/message-id/20200317195616.GZ26184%40telsasoft.com ... https://www.postgresql.org/message-id/20200317213426.GB26184%40telsasoft.com The scale factor is relative to the reltuples estimate, which comes from vacuum (which presently doesn't run against insert-only tables, and what we're trying to schedule), or analyze, which probably runs adequately, but might be disabled or run too infrequently. Since we talked about how scale_factor can be used to effectively disable this new feature, I thought that scale=100 was too small and suggesed 1e10 (same as max for vacuum_cleanup_index_scale_factor since 4d54543ef). That should allow handling the case that analyze is disabled, or its threshold is high, or it hasn't run yet, or it's running but hasn't finished, or analyze is triggered as same time as vacuum. A table with 1e7 tuples (threshold) into which one inserts 1e9 tuples would hit scale_factor=100 threshold, which means scale_factor failed to "disable" the feature, as claimed. If anything, I think it may need to be larger... -- Justin