Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM2a1-001Fal-07 for pgsql-admin@arkaria.postgresql.org; Fri, 13 Dec 2024 10:07:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tM2Zy-004b3g-Ff for pgsql-admin@arkaria.postgresql.org; Fri, 13 Dec 2024 10:07:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tM2Wn-004ULc-TX for pgsql-admin@lists.postgresql.org; Fri, 13 Dec 2024 10:04:11 +0000 Received: from sonic301-20.consmr.mail.sg3.yahoo.com ([106.10.242.83]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tM2Wk-002ccm-RQ for pgsql-admin@lists.postgresql.org; Fri, 13 Dec 2024 10:04:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734084241; bh=3oFFePVinTqEzzVMFcBjzBtRufkM9PBfT8G2v5tPw2s=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=QXMNe0khbhlNshvwWrHmft4bUyUohUcA+WdiZLc6yOhdqaIcOApUlI8t/wAnfNF+7DZWgYzsEWz6+QM7+Eh8Dt2ygoozTzW1PSG1W2nwtbXhjzHo3D98z3DMz9EeJgp4XydScVaHY6sA1MHqHNt/mgt4dCzv2Jvvh0IRKvz1VYqmvJVhVNMnxyJHQ7FS66ysUTi7ATynedIpoZfUSo/vTEYJYxAooShQ1jDcJmHCpNuJ1pXnLGbbI2TjilvBPm/f41fUh/u3Eg+cJJaWEqc22M2NaW30GY8qYjU8iOhesgwU65521bIhG/Us6vCbgAlH+lDx/R3DuJTtw/+q6wS95g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734084241; bh=gPZnkKTYWRLmgNKgDfCF4oxcsKGHslBjfTb3WQxjOhp=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=LzAuzqlTjObd8OpQuexWY5/NhcsUsCkhcs/AH8a2yuAgYSUUnShCQ5LFedJ0n4BEMYVXHs+UR99DfC6AHcJIQLDHkfqGWFoPlFDsLFjYDBKsOLL0eV9zSvnTK3MoFygGPN9WtOqqxy73vIsI3pn4YAJ8HsWVRz7UG+AF+mMCcFJfTeoERs4CEzNH7TodEz6b/b3GoaBKWg2uyRw28QUFe5v4VYXID0dwpNQZlagXWCpTwITOWPHrYx6X7e1ubU/KS3b3Hg791We7g/hlDOehP5/S3q9xTw/rGbf4iBjcorTLEnNDrBNzg4eBsGL0P96+P6aIGEpI+4DAK5hoVmQwWg== X-YMail-OSG: m2SZXTIVM1kq_10iwq4nyJfueUVzGur.WOtvvTro3tcbD5qbKU8GFIneduRjKU2 5Bjkh9iNHdkc6bALH8cxXH98OrcsuNxwRcFWssAhQDJtGQ72wzAPZLnWPM4ld0GQ3S3K7obTZYt5 zRCK2PxnyeNEK2mv7En_K4kkFR2lBGk5Nfht3I9IyRiNPh522Fz14Ldd.lRtujq8mPn2AC9_Ch_v vFa265FJuxYXrW2TEbem3ozfxS9daoIh91itpocXi8sJPKto3FUHzbHcolyB.QD4yqYOa3dK3p.i zGuL8OJQP9dsUEQo54yDM65Ys2ROy.5rog21T9QObhhPAMXzaxfYOwHtjAQgOt01paOpmNRbWCPy pHuxHvcEDjq5rZpRAqL_fyTiZyrFmbb_1K09r1gT.w5JA5vTIGFNdyLASd8Xfb6MPzVakDy3AZ4f YOq.xb2_rjulUJcUkSHk5Dd9C5xhI9__Yzox.7YuRvN_7us0t4XthsUFE181PP1RTQKNBrIQLo2H ntMaboVauUkT3kQYISXP5BCE0J6_XFfkbjAco74aRGp8s_KbyYXp1CTyELq64qNhZoHLsDiT_3DP qvWAy.UuOVsSazXYaKfm0XZihZEW10KUVG.X0TkfUH5D4c2BbMqTOfL7OKyMHXgNk8ohQA6hr.tM Kd2OqLBWtnXDZ6bb.H7icblBgadt9lKnJ1EOI2fubp_yxFP6Xb2XwAGVMpsOHslFEJDdtYx.27cJ 26vDCBxEFekeXTtTyvzwfS_PMDm.EcTE.l3_Qhm1jYHiZiYDQI_wLbCSLcyPEHrhiWAYTJgAmL0a JUR6nCKEfwAjvmG5ofKsAr_xD7_NPdgJiru_2OeFRIMLGMc.7wg8SYnQ8l0So1ddTRUkfDRkaZ5s BLzybVXZJsY3NOzcG6aFWA2cMngtUPShk7JbQHuCsC0MwAJetSlNUkuPd8ho2CPhwxcxxMfexbwf TElyy4ZD3SsT7sq47caXP5JX.34a.CL_3Ic_NMIfuX0jHNyIy3bxtl0Fijtj3oITaASFacJZnMyr 525i36oZNGFI.2c_QUD32878664zlzRi06Gc4ZRyah1Uo5OkZEFN7w6M9Oe8XPx3Lzh7CbWZ1_6I .HZKNNuykQ689rY0D_0liwkEq1tJ_tefzMcE6SYDAkuci5MCe0c4L5xWtFlK_VR7z1wA1HCFQpuw uTeodv.EX02cG600SH0rzT6mD_mkWbW6JVGpDhaYfdG5Lm1CaZQZZ5MotDiQbZjDflIWI6V8Ch0R hKOEZqSgx3aE2r6o_.S.HNewH4j8odEzZ9BnN6fOgYFfjuurfo77shqx.Cjfjvaa4wHu02oG5j5y HWKsanv9OXCzdhb5S_wqtDFXjWN5HDnumzpfmbYLhJugLZk4DD2r2fTmBIcHmhudp0qYaG3Od9eh vqb6FZXqjWZbZLFk697UzUq7lj41U1C58kx5JbffsIVxX8YHxNy_xocb6Xm_W85XVzC8u4FpzDjZ _ZFCVr.2GLt00.AmYqlTtA4Y66DyST0HDPt8MQ1XQm2TWX4_zJPu3WvkXCtXb6J0_CQ9Tl5kwl_u HUVin.EXiGN.ZbG517B4D4qEGXitQwhKDTRI2toqyIqXrD5RbfxztdeOoBK3y8hziJCrCJ2dWcT5 QwErVjfEBfnWVED7XwWujhg7lpIrqJTwgoHQa4_Oj7xwhYyUOJ5zOwAlJL1wk7spkqjL5YqC7KuQ aIGtlfB.qhEHv8qQVxEZRaD0JkKZqRlQev1cluvJ2vpRUPQO26TxGXRX88BcQh9nGgoE9.diFW4K Gq3lH9qr0eWesTSYuLFaEWmgMkzx9JhE.H9p7vJxPzRqJh6T0keMKOBEqZHhAL6qZvy9NtkwOHle 0PnTrfDLnIj82TLrjQf3sNeRtmPH3.MlM8zFDtZi2w4VJndkuFF9Q7Nhob9s146F6vLfHt5e2IHC Swm2CDWmLrVsmMtyi6XOgeR5llvyzODROdZex8mnysjiN7LRRqz1C.6rCOpEnrIYut9UR6pUn81w 4bIdEa63ktZOlw5WIkt4ITUYEXBgKgTNHLVnaZIAVdPDxn41HSgf_D50k2ee2WsEpw7v0febi84R C7EXldQTTfIWNjVRVqwIUUi_d5p9xLnUGSj4a6IKWTdSZrx4h.gwC2OUYRC2B1BLIj3uUroiS6rI x8faZJYu3LxTGGT.IN7teLuvbDQZWMCxb63TIaL5SN_0Prqj.0kH3mYwhUDhWiY.bsz1sogz74jU .yQ_O8.sMrhkW8sezHOPQNBZ5QlXCMehM5VMZYEfEnu_lopXGc9OV78VZiUJ34mBY3MZLfQGKvw- - X-Sonic-MF: X-Sonic-ID: c57ca38e-e4bc-44e1-b5e4-dbb2a21925b4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.sg3.yahoo.com with HTTP; Fri, 13 Dec 2024 10:04:01 +0000 Date: Fri, 13 Dec 2024 10:03:51 +0000 (UTC) From: SASIKUMAR Devaraj To: vignesh kumar , Pgsql-admin Message-ID: <1727122332.1852194.1734084231873@mail.yahoo.com> In-Reply-To: References: <155477463.1496353.1733983706261.ref@mail.yahoo.com> <155477463.1496353.1733983706261@mail.yahoo.com> Subject: Re: VacuumDB generating huge WAL filed MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1852193_471542964.1734084231872" X-Mailer: WebService/1.1.23040 YahooMailIosMobile Content-Length: 4326 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_1852193_471542964.1734084231872 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We were able to identify the table generating around 40GB in few mins by va= ccum process. It is partition table with dead tuple less than 0.5 percent. = What may be next steps? Sent from Yahoo Mail for iPhone On Thursday, December 12, 2024, 8:37 PM, vignesh kumar wrote: Check for the max walsize allocated in postgresql.conf and also check on ch= eckpoint completion target default is 0.9 this says how frequent the checkp= oint can be applied that adds to wal lan generation. First do a table level vaccuum and see what's causing it to write more wal = files. Sent from Outlook for AndroidFrom: SASIKUMAR Devaraj Sent: Thursday, December 12, 2024 11:38:26 AM To: Pgsql-admin Subject: VacuumDB generating huge WAL filed=C2=A0Hi All When we are running vacuumdb for our database of 1.5TB it is generating app= roximately 60GB of WAL files? Any way we can reduce this WAL file generatio= n? RegardsSasi Sent from Yahoo Mail for iPhone ------=_Part_1852193_471542964.1734084231872 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit We were able to identify the table generating around 40GB in few mins by vaccum process. It is partition table with dead tuple less than 0.5 percent. What may be next steps?



On Thursday, December 12, 2024, 8:37 PM, vignesh kumar <vigneshkumar.venugopal@outlook.com> wrote:

Check for the max walsize allocated in postgresql.conf and also check on checkpoint completion target default is 0.9 this says how frequent the checkpoint can be applied that adds to wal lan generation.

First do a table level vaccuum and see what's causing it to write more wal files.

From: SASIKUMAR Devaraj <sashikumard@yahoo.com>
Sent: Thursday, December 12, 2024 11:38:26 AM
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: VacuumDB generating huge WAL filed
 
Hi All

When we are running vacuumdb for our database of 1.5TB it is generating approximately 60GB of WAL files? Any way we can reduce this WAL file generation?

Regards
------=_Part_1852193_471542964.1734084231872--