Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWwtH-0003Ir-Tu for pgsql-performance@arkaria.postgresql.org; Fri, 08 May 2020 06:53:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jWwtG-0007uZ-Qk for pgsql-performance@arkaria.postgresql.org; Fri, 08 May 2020 06:53:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWwtG-0007uR-JV for pgsql-performance@lists.postgresql.org; Fri, 08 May 2020 06:53:46 +0000 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jWwtE-0003OI-36 for pgsql-performance@lists.postgresql.org; Fri, 08 May 2020 06:53:46 +0000 Received: by mail-wr1-x431.google.com with SMTP id h9so569678wrt.0 for ; Thu, 07 May 2020 23:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=JEUWJ4mEoHBTaSyWyAIsM2xxgjIGOtpw/iDQsSioRCA=; b=04ECAErnm5CwWAdPSp64ZLHkUg3Fh5gaK0tb8WVDwCvW5g6nM48ka1uFweW90SI2tj 8j2BZrK5SAiwiep99JGC3QfkRBMYexHHv1R0p2T3X+JjR7CWSp/VPhyC52xixqMv76/g mYHbMIq5ujQFJWaNNc0EAUb3mSpjDDdrYtKVwKARQi+8MIiblcyKE9VUVbuof1z+/fw2 DhsLi+Nzj+infcL/HDziYg7SQri+7Wpva+miXzYxZyPixZSF+w0vYEV4ViTVD/yBSWf0 vXhK1bTAjf6RenqSrW2q6a9EXmF1qif6QggLDejPigctDLFHmKc99ZFy9AXjK7umgvFw QGfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=JEUWJ4mEoHBTaSyWyAIsM2xxgjIGOtpw/iDQsSioRCA=; b=GlDarXpBT6rZlOqSLF7UWxsMwJKdB00cqrbvzanEgqLT8bRcrwxaZedBWcSYEF5VDS aA5ztsPPXyfCl0NOGB+QiuFA2SJRajkWus8r/aGb0Q0GjlUKJbrTx7lU012gAOrdNYqE nKzLzvT5Banfmlf+zYfwQB+Zo55dHca+vJZ97LRZw3hnLtsq8UIxZFdbJMmXorJh7ZnB ZEa5tHDZLBCdCSj3ZXOb2VxLmTgITCh+hIJccERNkT4exqmgCOYhTeMghQbWLIP6tETl jxEIKm4rCrU0vFCITE9T2WLcvxUtZgvoxqT/cRMvKKCpxt/w6yN43ndKR5GdV7GYv2sx eZHg== X-Gm-Message-State: AGi0PubFUd/cfXAycOH45cb8o8oCBdsvJYpF7AI26mPMTlDCLi59A3B4 qQANnNpCByvQOSwveBBruIjrWA== X-Google-Smtp-Source: APiQypJstQnJIg+0u8kZKT0kp1fWdovkJLthyQa1NLwj4Sfq4Y8cEB5L0qXEX3lla+kNYRiDxRjlKg== X-Received: by 2002:adf:f344:: with SMTP id e4mr1117444wrp.395.1588920822837; Thu, 07 May 2020 23:53:42 -0700 (PDT) Received: from dynamic-emngbpawjaqsxvclq-pd01.res.v6.highway.a1.net (dynamic-emngbpawjaqsxvclq-pd01.res.v6.highway.a1.net. [2001:871:60:4ec7:c2c1:32b6:5a97:228e]) by smtp.gmail.com with ESMTPSA id 33sm1414629wrk.61.2020.05.07.23.53.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2020 23:53:42 -0700 (PDT) Message-ID: <8f67073e5a6818a17eef5c44b087640db8939f7d.camel@cybertec.at> Subject: Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants. From: Laurenz Albe To: Avinash Kumar Cc: Rory Campbell-Lange , "David G. Johnston" , samhitha g , pgsql-performance@lists.postgresql.org Date: Fri, 08 May 2020 08:53:41 +0200 In-Reply-To: References: <20200507210846.GA17040@campbell-lange.net> <17c5b15451fac2ace7a815d1d2c8f86e1d232802.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, 2020-05-08 at 03:47 -0300, Avinash Kumar wrote: > > Just set "autovacuum_max_workers" higher. > > No, that wouldn't help. If you just increase autovacuum_max_workers, the total cost limit of > autovacuum_vacuum_cost_limit (or vacuum_cost_limit) is shared by so many workers and it > further delays autovacuum per each worker. Instead you need to increase autovacuum_vacuum_cost_limit > as well when you increase the number of workers. True, I should have mentioned that. > But, if you do that and also increase workers, well, you would easily reach the limitations > of the disk. I am not sure it is anywhere advised to have 20 autovacuum_max_workers unless > i have a disk with lots of IOPS and with very tiny tables across all the databases. Sure, if you have a high database load, you will at some point exceed the limits of the machine, which is not surprising. What I am trying to say is that you have to ramp up the resources for autovacuum together with increasing the overall workload. You should consider autovacuum as part of that workload. If your machine cannot cope with the workload any more, you have to scale, which is easily done by adding more machines if you have many databases. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com