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 1nHRDj-0000rD-Ek for pgsql-admin@arkaria.postgresql.org; Tue, 08 Feb 2022 14:11:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nHRDi-0001n5-7X for pgsql-admin@arkaria.postgresql.org; Tue, 08 Feb 2022 14:11:50 +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 1nHRDh-0001mw-Nh for pgsql-admin@lists.postgresql.org; Tue, 08 Feb 2022 14:11:49 +0000 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nHRDe-0005rK-OA for pgsql-admin@lists.postgresql.org; Tue, 08 Feb 2022 14:11:48 +0000 Received: by mail-oo1-xc2e.google.com with SMTP id o128-20020a4a4486000000b003181707ed40so522860ooa.11 for ; Tue, 08 Feb 2022 06:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=DB5CJ3XTnI3g9tCfwpmAYokiKexdxUFlGOzDwKv7fVc=; b=KcuSnEmDkqS+mXN3jAnkqKFTg4OuX6fg381CBH0R8UeJcZ+HhTTN+E6ALPvaaQGN9g R1d0f9mthY+eciDQFFNWFwGo0KSREgdxVtRnofPBgzjh00YmVQVMJzO2CQrnrkkEgGvm 6V5lMxCCuZjWUsF2P76ulDCK7bkjzrOPcwkFOH6dPGBhgsQKK1vV55jAl6iHX/PWBM1J 6VBTqjlcoj0ey87lD8C0a6TatvXrqQkiaOlgHhOWS+iK0H+QD3SrpYENam0q71uayfLe UVEF2qwtPR13X/o/8g7AiAcWmAB2/zKWT3YROg1VdRH8Gfc7ZWMEfJobiwOi5Adv3gqW R98A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DB5CJ3XTnI3g9tCfwpmAYokiKexdxUFlGOzDwKv7fVc=; b=6WIwume4dn8HeSpAUx7CF9LDjuXY4IvZ+dBwhk8a8VgxISH+n3lpR9lp2Cos5/DxUt tA7yp4xSGnQ5g7DCZG1Mi/lQQ4GRFDqFbBdBVSJadeVSVIicsuG4+TYO6XAhUjrJSODQ qRERxeG2AaOup5dI64IWdlB9Wbs40YPgUWbDJxF2YNxIhmBuc0eXWOIyMKLIZXWdrS3g a/7FEWwZZ+V6vdjuik+cgwj1holVx1Sp+jFl5G+JGcG00jSmWCkArMxoo96nSjSX0/dI poXdGsjUrZGwzPyR/B8xPXeDkbD0nUGwRlfue8cDYZksKoZP9eGriTGbeTegZsLHr2uT mv7g== X-Gm-Message-State: AOAM533rwf+gRMWBfyhgSyG+ygR81cEU35rd4KO+Q0mY4TZ8+1BNG4cw L/lTJ5U6nYDCWzgoy9IY3sq2xvD1Lv8= X-Google-Smtp-Source: ABdhPJz4ghGRvAeHpjDa8Pizb8qWzG+jkv+1/URb0tCi7if5OTjuyI4QECQ+k/8mZXN+rK0WrrQ1Rg== X-Received: by 2002:a4a:d5ca:: with SMTP id a10mr1794564oot.88.1644329505965; Tue, 08 Feb 2022 06:11:45 -0800 (PST) Received: from [192.168.88.10] (ip68-11-68-85.no.no.cox.net. [68.11.68.85]) by smtp.googlemail.com with ESMTPSA id 2sm4123820oaz.24.2022.02.08.06.11.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Feb 2022 06:11:45 -0800 (PST) Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. To: pgsql-admin@lists.postgresql.org References: <20220208065324.6lrlrqxvau33k5gk@jrouhaud> <20220208070826.6q7tgzumlumzlles@jrouhaud> From: Ron Message-ID: Date: Tue, 8 Feb 2022 08:11:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------31C6D8E3360B2EE5F8F30C94" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------31C6D8E3360B2EE5F8F30C94 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Maybe your database is really big. Maybe your storage subsystem is really slow. Maybe you're only running one thread. Maybe it's being blocked by other users. We don't know because you've barely told us anything. Not to mention: VACUUM FULL is *only* useful after you've updated or deleted a major portion of a table all at once. On 2/8/22 5:22 AM, Ram Pratap Maurya wrote: > HI Julien, > > In my current database index size is very large compare than table (if table size is 30 GB and index size is 90GB) , that why We running full vacuum monthly basis to increase the system performance and data reclaim . > Auto Vacuum is also configuration in system. > As per your suggesion if we increase " maintenance_work_mem " paramater size to 1GB this will be help to improve full vacuum performance?. > > System configuration as below: > > CPU - 42 > RAM -70GB > > > > Regards, > Ram Pratap. > > -----Original Message----- > From: Julien Rouhaud [mailto:rjuju123@gmail.com] > Sent: 08 February 2022 12:38 > To: Ram Pratap Maurya > Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh > Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. > > Hi, > > Please don't top post on those forums > (https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics) > > On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote: >> we are running VACUUM FULL on all table and its take 5 to 6 Hrs. > The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem. > > But why do you need to do frequent database wide VACUUM FULL in the first place? Do you really have massive bloat on every single table in the database? > > Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough? > > -- Angular momentum makes the world go 'round. --------------31C6D8E3360B2EE5F8F30C94 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Maybe your database is really big.
Maybe your storage subsystem is really slow.
Maybe you're only running one thread.
Maybe it's being blocked by other users.

We don't know because you've barely told us anything.

Not to mention: VACUUM FULL is only useful after you've updated or deleted a major portion of a table all at once.

On 2/8/22 5:22 AM, Ram Pratap Maurya wrote:
HI Julien,

In my current database index size is very large compare than table (if table size is 30 GB and index size is 90GB) , that why We running full vacuum monthly basis to increase the system performance and data reclaim .
Auto Vacuum is also configuration in system.
As per your suggesion if we increase " maintenance_work_mem " paramater size to 1GB this will be help to improve full vacuum performance?.

System configuration as below:

CPU - 42 
RAM -70GB



Regards,
Ram Pratap.

-----Original Message-----
From: Julien Rouhaud [mailto:rjuju123@gmail.com] 
Sent: 08 February 2022 12:38
To: Ram Pratap Maurya
Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh
Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs.

Hi,

Please don't top post on those forums
(https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics)

On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote:
we are running VACUUM FULL on all table and its take 5 to 6 Hrs.
The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem.

But why do you need to do frequent database wide VACUUM FULL in the first place?  Do you really have massive bloat on every single table in the database?

Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough?



--
Angular momentum makes the world go 'round.
--------------31C6D8E3360B2EE5F8F30C94--