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 1kpiN7-0001Do-OG for pgsql-performance@arkaria.postgresql.org; Thu, 17 Dec 2020 01:46:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kpiMa-0008UL-86 for pgsql-performance@arkaria.postgresql.org; Thu, 17 Dec 2020 01:45:52 +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 1kpiMZ-0008UD-Tp for pgsql-performance@lists.postgresql.org; Thu, 17 Dec 2020 01:45:52 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kpiMW-0005e7-8w for pgsql-performance@postgresql.org; Thu, 17 Dec 2020 01:45:51 +0000 Received: by mail-ed1-x533.google.com with SMTP id r5so26935462eda.12 for ; Wed, 16 Dec 2020 17:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lTyU6MKEonIFXjFBQ0cSOlYXA63HrnZoGeKmlVaTxSI=; b=M8rrU08migz6K97HHsvk/OPxRy40Fn3IuNXfbj81pR83fsx5CEKcf1wff+zzLunGNw F/av4CZNstxpMspwomfrtwK2X4bm2ybLViV5s1ZcsLczufl3uELj8qDs0E2g8CJjVnyY g+RVqFRqBhVy+6gVQzg8NTEOB+thfbJiN1JcHCXw+sKcLSEEG4+9Hilqgh2wuZjZ2+AH NKq233XRv13k1gseNq8ntIXOBDKksiwinbLbE3cM6VyKx0HCBxmA0sUb3K+5AbTGsMWH 2Bv0ehhvwdAYWcrUIU+MGnZpL8RZ/1n3JkbGTkxWy1DOdjpxDS+/m9a8SoeQrChFwQ1b 8lxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lTyU6MKEonIFXjFBQ0cSOlYXA63HrnZoGeKmlVaTxSI=; b=SxDibV6QhajyOJ/iBg/3J60XV7ORT5YR4ukmIf0yg84JMCkgrtZcateruVewSWIdhf kixi2g/gNIf6HBcs0rmV3OFPBmqWBsfMMLD/zBBI2JN2gWNhwzcoOVNTuTpV/t1WWSXn AuIzmfuR7SXG9cEU0tBJoRtmI2BiYpD3TQxgoR3W1fz3pg8TwnlzpoMNWGTucsAqGzJH CVpvpN++ptNhW/DSZRnpAlLUkhAM+4V89TfB1I/UevoKwYH+JWi21CZorVwz0SpG/8uT sILDzU5vjHFZaBI+st7p8/dIuUeMY3xDEuIRcQtRxXx3u1duIsFDNY97Md9THKO36oRN go+w== X-Gm-Message-State: AOAM532CAsaFen0GrwR9f6IDgcdqpkrhYyHi9umhQ4sYeh8C+zHDmz/J RSntq2XiXK4nMfegyTPPasMJ7wUf50GchaSyH47NNZFNtThitWOwzfrTxsim80pTwPG0jlOZulc TNHsGBrbcy6dCrtwfjhYyB9Xi+4pZ6o3JivHJAH8/uNj5jTTNp3H6Hcx1EbLZuUnK74u3mbBmU0 EV6ySfFwjXB7jIeZsrUD0odMjNKoyMlxWSpHSpkqzinCGrBUg= X-Google-Smtp-Source: ABdhPJwAKjLxrWKcoqr8uGMAqlqaZU0LYOoOj5VZ09Npb4TFO4RZS6WK3ST27eFkzVhEiNlX2LvgAQ== X-Received: by 2002:aa7:c886:: with SMTP id p6mr36963357eds.207.1608169546262; Wed, 16 Dec 2020 17:45:46 -0800 (PST) Received: from [10.137.0.19] (ip-86-49-249-71.net.upcbroadband.cz. [86.49.249.71]) by smtp.gmail.com with ESMTPSA id ck27sm22547176edb.13.2020.12.16.17.45.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Dec 2020 17:45:45 -0800 (PST) Subject: Re: Autovacuum not functioning for large tables but it is working for few other small tables. To: M Tarkeshwar Rao , "pgsql-performance@postgresql.org" Cc: Neeraj Gupta G , Atul Parashar , Shishir Singh , Ankit Sharma References: From: Tomas Vondra Message-ID: Date: Thu, 17 Dec 2020 02:46:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 12/16/20 12:55 PM, M Tarkeshwar Rao wrote: > Hi all, > > We have facing some discrepancy in Postgresql database related to the > autovacuum functionality. > > By default autovacuum was enable on Postgres which is used to remove the > dead tuples from the database. > > We have observed autovaccum cleaning dead rows from *table_A* but same > was not functioning correctly for *table_B* which have a large > size(100+GB) in comparision to table_A. > > All the threshold level requirements for autovacuum was meet and there > are about Million’s of  dead tuples but autovacuum was unable to clear > them, which cause performance issue on production server. > > Is autovacuum not working against large sized tables or Is there any > parameters which  need to set to make autovacuum functioning? > No, autovacuum should work for tables with any size. The most likely explanation is that the rows in the large table were deleted more recently and there is a long-running transaction blocking the cleanup. Or maybe not, hard to say with the info you provided. A couple suggestions: 1) enable logging for autovacuum by setting log_autovacuum_min_duration = 10ms (or similar low value) 2) check that the autovacuum is actually executed on the large table (there's last_autovacuum in pg_stat_all_tables) 3) try running VACUUM VERBOSE on the large table, it may tell you that the rows can't be cleaned up yet. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company