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 1pyKQr-0005r1-LP for pgsql-admin@arkaria.postgresql.org; Sun, 14 May 2023 22:43:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pyKQq-0005fu-HC for pgsql-admin@arkaria.postgresql.org; Sun, 14 May 2023 22:43:12 +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 1pyKQq-0005fk-6r for pgsql-admin@lists.postgresql.org; Sun, 14 May 2023 22:43:12 +0000 Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pyKQn-002Lqs-P3 for pgsql-admin@lists.postgresql.org; Sun, 14 May 2023 22:43:11 +0000 Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-ba729a64ba8so2269649276.2 for ; Sun, 14 May 2023 15:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684104188; x=1686696188; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NFGI5TIv6BeTQOEoGAAPX1CS3lA5iI8jr0Uy+FR9L4o=; b=pBgByB05GWQC58J93UWz+ZKd4CTFKJD5ve3kr6ozULAvVlZsg3wOnFEyNFr6E6SoT/ XzZoRQdA61y6S4JOkFJ8v9UeAIUmn9uWi10YbjKUpQKO7AUPx1mwYxwMn1Wx8SvrxB/a VBOuXFjJVJBohaC/xAY4XcR+mTzWFE0RN3QZHRtRhlySinVoHUCvT9LJm58m8djydNSK yHH9++dw+gTWKXnQxMHmeQhRXDegnpbFFyClwvi20fHL0aj8S6UTuHQkaCj4/Opr7vux IAci/QTFTZj3EoTPG5QWZdMjyMz7zbqOLuF4/kWO7FDHaWc7ssPQzNvp5YPaD2qDNLuu ePjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684104188; x=1686696188; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NFGI5TIv6BeTQOEoGAAPX1CS3lA5iI8jr0Uy+FR9L4o=; b=ilxz4L1YWWGF08NgSgxOKcdkR3vAu9zeGrjL3kFOtzPF/hfiMMiKcARW5domARUBmp XDJpWApIy5TjM/W2rklkjPiRgsSK9bv64YwEyzBmziPkBtTirze5AmI9/67XV+LSlUei pYAbkAKeOrHGXf2AQpti+5se0IQ3iuIBws64g+qJohHBDU+fQpshA81GRO3a3ZfM0mTc w6LEacmyR1x0GWcfB/RO/NIdL9SYWKjOI53I6ldKK+cwIqeL4Tx62NaSJrw1syhMVOKU VPj0X66ddS6a4mEjZcQn4U+nuYGTDwVuwhqIm+gCBlv9YJh9Qy7MnihCUt/PxhU/BaM7 X0FA== X-Gm-Message-State: AC+VfDys8AMI0LFT3WizmsXhEw3628aF9dz2wof5cHKtH79Mx+DHsmq2 s1dQguae3l0lbxlkZA8CTTYp1HhvXkU= X-Google-Smtp-Source: ACHHUZ6gTlkMlijL374WLb+tfmjNb/RTF5NHC88H29R6qqp4EZJX4CvTsaykXl6jSpczE8ZUoIgI3g== X-Received: by 2002:a25:53c7:0:b0:ba6:ff4f:e83c with SMTP id h190-20020a2553c7000000b00ba6ff4fe83cmr7431697ybb.1.1684104188180; Sun, 14 May 2023 15:43:08 -0700 (PDT) Received: from ?IPV6:2600:1700:bd2c:b810:80f6:4741:9863:ef90? ([2600:1700:bd2c:b810:80f6:4741:9863:ef90]) by smtp.googlemail.com with ESMTPSA id t18-20020a257812000000b00ba7da8f72ebsm86811ybc.0.2023.05.14.15.43.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 May 2023 15:43:07 -0700 (PDT) Message-ID: <99a9d881-235c-d997-026f-16dbea570c6e@gmail.com> Date: Sun, 14 May 2023 17:43:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Options for more aggressive space reclamation in vacuuming? Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: From: Ron In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 5/14/23 12:45, Wells Oliver wrote: > Noticed over the last few days how much more space VACUUM FULL reclaims > (for obvious reasons) and I am wondering if there are any solutions for a > more fruitful VACUUM without the locks of FULL? Another tactic for UPDATE-heavy environments is to reduce the table's fillfactor.  As long as an indexed field isn't modified, Postgresql will try and use in-place updates of these HOT (Heap Only Tuple) records. -- Born in Arizona, moved to Babylonia.