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 1nY1Oq-0004mZ-Uh for pgsql-admin@arkaria.postgresql.org; Sat, 26 Mar 2022 08:03:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nY1On-000441-Nv for pgsql-admin@arkaria.postgresql.org; Sat, 26 Mar 2022 08:03:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nY1On-00043s-AD for pgsql-admin@lists.postgresql.org; Sat, 26 Mar 2022 08:03:49 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nY1Oi-0001rW-33 for pgsql-admin@lists.postgresql.org; Sat, 26 Mar 2022 08:03:48 +0000 Received: by mail-ej1-x636.google.com with SMTP id j15so19311110eje.9 for ; Sat, 26 Mar 2022 01:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=8VkTbdDkLkZWLMfwP6vrd+8d/Mh+IiaZ1DA+/3VxzVQ=; b=ucYTfqy9tGliCjPNQ6Q0AcRUPX1xoE2hcQBNpmyKSs/D5icRR5VKERs6UevXw2f7fY hWEq+5xe1XZYIKEGK0LGLnU3Nlxuh6brR5AtvFDEYHLJbYLO43NyolPcIAczFAMjWZAb TqjnqgmT5hKu0IoRaVUXW3+HI5MMmXjK9QoMtdnE0PyR8niDPfDQcgIbSVNtBe74NUhU tcfoEC/AouUwmaZEz5F7iTBqNb2u9RKRDjK8kiRwTjajOR23nVlfpXwLnI7tGU8Qiyi9 nxSPTSCgwg6KmMXAPgdt7tX+4xrUAeIww+plpbUiDWxq8Eu7SxspPxHYKuqoCpu0QnEM ELWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=8VkTbdDkLkZWLMfwP6vrd+8d/Mh+IiaZ1DA+/3VxzVQ=; b=VixhBMfCdOZZxEJG/NqZJAYrRoyapxkG7pPIT7rwOfPkWl0nQec2mKyoFQeF3Qb6dS jzHnq8+Vr4Yvw5UU6D+5sMlXMvDAnd9YQqRtFbOVXQlCHOYhFr9JDnDU90QeIGt5flix RYiuz+EKoYx5cUEnWfpYYs0diKUbHkpsPbzkfz729HPYnfbOnLnSLfpib0wgSLwfJsKG 3RadwTE2zd8j0n0vJChbhw0ckI3Jjr/VJfJIhoDlPV5BCD/18zwn1XA3Q8Ko29kX+2K0 5Y/j/rJbCvuJrc+BodZnesvCpBgMxmMY3MERs340qSv1cDNkQZc7SCWo7ADH3kb8klCu PIOA== X-Gm-Message-State: AOAM531HXsYeqtN4xSuV7GseQeg4QuGnL/suIh/AZuhTMyB3dNqoFI4u pjJTR6d1ah76bNYwqLce2N/DikR62foCzA== X-Google-Smtp-Source: ABdhPJzMlOtyj44gQYELRRAMe+nOJGA8YCDYGLYnrwC5Ct+Jx7SrzYioAh2JX7rwhuVYm3eiQTWPjQ== X-Received: by 2002:a17:907:1b20:b0:6da:649b:d99e with SMTP id mp32-20020a1709071b2000b006da649bd99emr16057636ejc.712.1648281821596; Sat, 26 Mar 2022 01:03:41 -0700 (PDT) Received: from localhost.localdomain (178-190-183-69.adsl.highway.telekom.at. [178.190.183.69]) by smtp.gmail.com with ESMTPSA id b5-20020a170906728500b006db8b630ebdsm3195879ejl.209.2022.03.26.01.03.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Mar 2022 01:03:41 -0700 (PDT) Message-ID: <2f793dec73ab3798414574bda751e668d9d47ed8.camel@cybertec.at> Subject: Re: Avoid Wraparound Failures From: Laurenz Albe To: Loles Cc: Ron , pgsql-admin@lists.postgresql.org Date: Sat, 26 Mar 2022 09:03:40 +0100 In-Reply-To: References: <965a52fe849ec6e5759d349b4063b5077353f24b.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 2022-03-26 at 07:47 +0100, Loles wrote: > So, if I have understood it correctly: > > 1) set autovacuum_vacuum_cost_delay from 20 to 2 It is not strictly required, but that will keep autovacuum from taking forever to process your big tables. It has no influence on manual VACUUM though. > 2) execute, only for the largest tables, vacuum command: > >    vacuum tab1; >    vacuum tab2; > >    and so on If you don't want to wait for autovacuum to do it automatically, yes. > 3) Sleep peacefully :) Definitely. This is normal behavior. > Another doubt: query filtered relkind = 'r' but there are also sequences, views, catalog tables... that are also close to 200 million. Sequences and views are don't need VACUUM. Materialized views and catalog tables do. > Vacuum the catalog tables too or is it not necessary? Same as all other tables: do it manually or let autovacuum do it automatically. > I understand that the views, sequences and everything that depends on the table will improve by vacuuming that table. There is no influence on sequences. VACUUM can improve the performance of some queries, but mostly it is about keeping your tables healthy and in good shape. Views may benefit just like all other queries do. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com