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 1tOGiU-005Fnu-CT for pgsql-performance@arkaria.postgresql.org; Thu, 19 Dec 2024 13:37:26 +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 1tOGiT-00DSXF-JT for pgsql-performance@arkaria.postgresql.org; Thu, 19 Dec 2024 13:37:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOGiT-00DSX7-8Z for pgsql-performance@lists.postgresql.org; Thu, 19 Dec 2024 13:37:24 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tOGiM-000O8h-Ah for pgsql-performance@lists.postgresql.org; Thu, 19 Dec 2024 13:37:23 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5d3cf094768so1266222a12.0 for ; Thu, 19 Dec 2024 05:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734615436; x=1735220236; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=vXwZQVb0rwol/5f1QpsxY9MFZNAdP0I6Z0BDpciaKmM=; b=SxgIfnKW8aRDSzS5/8bLpIMR8mvC//jxc6Hb5JezbPrXrn/gjnbWSbdS6TGjSFW72V KPmBtv7WMasE14ko51oMJix3pwa0pa44qIRquuZGjylslgtYunJMpekOKYaIGe5XI0kM 23ZwVBWejF2bhuE8WwFSgg9W5TTlDZ3Yxz8C2bXvAMZqMB151cDNhqP58mgym1WBC1TP HxyqiRoINkMOOH2mDBOtOwvdxYj6Po9aII/64/da2OQ6gub/g+N7bD2EILjuWsd2vbjS ee9BeCDwMKTkDmTl8IMv/sQDKLiPcPDj43djvkspTHvG5A6xXWZ53cz2bTD9iSftPYdy 9WUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734615436; x=1735220236; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vXwZQVb0rwol/5f1QpsxY9MFZNAdP0I6Z0BDpciaKmM=; b=OLWnkyLBBYaJbCQlDsM+zs5LfmRr+EpvXdA3ebDjnYK1878SoBCuJnSR4u9MvH7kWk m3BfwxiTxFMwbhXqje7MKzypuKmmktgpMDgK1Xe7BM6EG7yzPWdq1ANLL4BT9Z2Nxh1P dRvESkJ3WsyFbQEdnlGdGFiG+CuAFKyD90jaZ/+G1qAYtsGTQQFOxk/aqDBGf9Zbg0ES ci8CYVNr4sCGEw1oim0IrswlqXZmg7ZdDM3QI7uA1cVm/C/iC4R7c+/O3h6m0rWvxKnS eMfvFofupVlNPhmKDI6D5B7a9Ic9ygbD+2AvU95zWGp+VfM73r7HkL4BtYWdoWrRzVW/ 6TSQ== X-Gm-Message-State: AOJu0YyT95AbQ06eR+oCxl+KcEEsAljIKOTrpdxtv7FRdpOHKJGmp7hY LRSybiVGIjpvmLAbvkxVPA1qA5pEGsr+pHkKgnvUeQ62APED/sIeNHZwOl/+nAIiwH0pGmz5Pb/ WpnLseJ2FeJ7ASCaT50S4dC4Nrw1f40DV X-Gm-Gg: ASbGnctmiViSbjMZokF6amMwDEy2HamYNw47AH6XvbtDjES6J2cO9Gkwe0PQfl7qaVZ W5ZvmpXqZoXP7pqZ8YilvH1cFrEieUoHyuSE= X-Google-Smtp-Source: AGHT+IGqJCNSi59ZukKUsGN2/PBdwApmpmebAWZiErANWnorlxFCfLY/Jcvbi0OO4aUbQUO02zeAb/DFJWE61luFkJQ= X-Received: by 2002:a05:6402:40cf:b0:5d0:d5af:d417 with SMTP id 4fb4d7f45d1cf-5d8025af44fmr2660941a12.1.1734615435399; Thu, 19 Dec 2024 05:37:15 -0800 (PST) MIME-Version: 1.0 From: Graham Hay Date: Thu, 19 Dec 2024 13:37:04 +0000 Message-ID: Subject: Aggressive vacuum To: pgsql-performance@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Can anyone enlighten me on exactly what triggers an "aggressive" vacuum? I have read the docs multiple times (and watched several videos!), but the changes I make do not have the expected outcomes; so I'm clearly missing something. https://www.postgresql.org/docs/15/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND I have a fairly large table, that has outgrown the vacuum defaults. We started by setting: - autovacuum_vacuum_scale_factor=0 - autovacuum_vacuum_threshold=100000 # 100K (10% was a lot of tuples). This was definitely an improvement, but when the big vacuum (freeze) kicked off there was a noticeable io/latency spike. We then tried setting: - autovacuum_freeze_table_age=100000000 # 100M which seemed to make it happen more frequently (and one would hope, with less work to do). We reduced this to 50M, and again it was more frequent (but not the 2x I expected). And when I dropped it to 10M, nothing changed. After re-reading the docs, I got the impression I also needed to set: - autovacuum_freeze_min_age=10000000 # 10M As the system default was 50M. And again, this had an effect, but not the 5x I was expecting. The docs say: > all-visible but not all-frozen pages are scanned if the number of transactions that have passed since the last such scan is greater than vacuum_freeze_table_age minus vacuum_freeze_min_age but wouldn't that have been 10M - 50M? i.e. -40M. Is there some other setting I'm missing? All suggestions welcome! Thanks, Graham