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 1ncPMj-00053x-MN for pgsql-admin@arkaria.postgresql.org; Thu, 07 Apr 2022 10:27:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ncPMh-0005Jc-Us for pgsql-admin@arkaria.postgresql.org; Thu, 07 Apr 2022 10:27:47 +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 1ncPMh-0005Ib-K0 for pgsql-admin@lists.postgresql.org; Thu, 07 Apr 2022 10:27:47 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ncPMf-0008V4-4A for pgsql-admin@lists.postgresql.org; Thu, 07 Apr 2022 10:27:47 +0000 Received: by mail-ed1-x536.google.com with SMTP id w18so5805221edi.13 for ; Thu, 07 Apr 2022 03:27:44 -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:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=Gz3xMuasNJTEZV15rJH0+8n9zFoQlEW9v1W2cHcusBc=; b=52bkKELVWR26nAaWoU4C5dCEIBe/Ef1F5G4uoRkGKD/QT/IEBh23ABinTONC6V5/lC nXvneDAmfkah+b5oGkwjebT6afu7PAMiMMKe8ze8kKhjqsvXydU/iJUmj7LnH78y5mWD 2JZHp8qYFyVUdt6uzeC5Nbg48dIPg/xkwwnb36K0GNUUoIgSYmHVFlM+nvPdOa8WwLcC 0fVG13DTQZMlLoTroKYD7NC2HoT8esVkxnJ2WDiKzRP4hpFTG/g6r25iJWYEXYBSHQ1r 1XmfBWAXxO0cGRzhSSdmJamDigYRf4bWE9uSNBqwQ/dPLb/0WgQuE+hxZkCPuazrSgXF CCdQ== 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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Gz3xMuasNJTEZV15rJH0+8n9zFoQlEW9v1W2cHcusBc=; b=ZvpTN+zOk6nxHLVmCWS74UDJoxyNayUYXhfx8To9ON/yua/uNS2/IHrpFoGIWgxLQa oX43vZRXo+2ja5CxUO1AqwfBX8qUQW6XUmU5+s1xPVDCmyc7ipK9VN5n6NgqonH9g4gL 9Ki403WS176jyrECMPwxAGXEEl6wjteYTDTXXfBYiPdLyK9Ekw08I11jAk0RHiLKGLaz Wp9kIK/73suNeqB/su+GqIyXg9bK+bGvTMfd8+/jMf+glrgNi1T4B67AhSc2NOv5ns7P GWq7/weXjeygfn2jPmLETLAx1UwCLsnuZgKd7KxhgSctR2r0XZnqstfxhAlzqPjRTrnc +oEw== X-Gm-Message-State: AOAM53043j8LW0e1xWw7XXbTohDKhR1FMUJke9v6ReZxJc5LvmD2idfU m8Jh2Abi/1eEBB1gUnIsJpAHEQ== X-Google-Smtp-Source: ABdhPJyspZU+OSIqSIOfNCuA5luXqt0tlbuHCnCDAxFXOA1jF8fJVNmVJfc7I3N+Tbq3m1ebw1lQEQ== X-Received: by 2002:a05:6402:22d8:b0:41c:c3cd:478e with SMTP id dm24-20020a05640222d800b0041cc3cd478emr13463005edb.34.1649327263893; Thu, 07 Apr 2022 03:27:43 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:1de5:397:ed65:99b:afff]) by smtp.gmail.com with ESMTPSA id dt6-20020a170907728600b006dff778258csm7532296ejc.32.2022.04.07.03.27.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 03:27:43 -0700 (PDT) Message-ID: <49a74a198068f02c507f2a5e4c533cc30d24adc6.camel@cybertec.at> Subject: Re: Autovacuum script From: Laurenz Albe To: Avihai Shoham , pgsql-admin@lists.postgresql.org Date: Thu, 07 Apr 2022 12:27:42 +0200 In-Reply-To: References: 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 Thu, 2022-04-07 at 12:36 +0300, Avihai Shoham wrote: > I would like for you advice/sharing  about a python script that will run overnight and do autovacuum. >   > I'm sharing mine below and will happy if you have suggestion to improve it , or sharing yours in case you have. > I'm not an expert of python or postgrsql so please understand :) > > The script below do autovacuum for the biggest 10 tables > ----------------------------------------------------------------------------------------------------------------------------------- > #!/usr/bin/python > [...] >           query = 'VACUUM FULL %s;' % (row[0]) I think that is quite a bad idea, for several reasons: 1. VACUUM (FULL) blocks read access to the table and is *not* a routine maintenance job It should be VACUUM instead. 2. It may not be your largest tables that require VACUUM 3. There already is an autovacuum daemon in PostgreSQL that takes care of that and has many parameters to adapt it to your needs. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com