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 1s8w9f-00GHwN-FK for pgsql-hackers@arkaria.postgresql.org; Mon, 20 May 2024 06:05:52 +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 1s8w9d-00GW3N-Ta for pgsql-hackers@arkaria.postgresql.org; Mon, 20 May 2024 06:05:49 +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 1s8w9d-00GW3E-HO for pgsql-hackers@lists.postgresql.org; Mon, 20 May 2024 06:05:49 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s8w9b-0014lF-3B for pgsql-hackers@postgresql.org; Mon, 20 May 2024 06:05:48 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2e6792ea67fso43743181fa.1 for ; Sun, 19 May 2024 23:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716185144; x=1716789944; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7OzgFWJL/57NpgbSp21Y9vM6inPAfer/L8f08VXosi0=; b=MZgBpxnZPeuChAArrrCCIJRXDFXp3jAP5WTURWSf6uqJB4GoG8LEVbro1Q5FUe4oSq zFlmDSbK+Be9cR4cgiSRPrQnz2TGX90LtrDIbEMxY1bgzzO0h/RBmTD+B0w86zd5JJZW OBnTJ3Z/Np09//8ei2FJn5SrOwyZWk+sBFffXK+EJacfSct+9TMyjRSG5odWNrtvc+Jt vEM2jyddUmp1wb8dJS0VoDWe05+XnE4tBxsCR11J1DV+maqkL7pTUmbb4cztEGCOJGMW 8H534KhU/it9aYZLYRmM9EEs4nMT1TMVViDItL4ujV645O4FpbvK0InBtN6u/6S7qXf6 hWDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716185144; x=1716789944; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7OzgFWJL/57NpgbSp21Y9vM6inPAfer/L8f08VXosi0=; b=fV4gYKVlUDBoAaG1zVSoEX2+UImeZWTXnZgMYfoMivQBuoqlWLv1oFQ+gG+h1ehO7s YYzWdMrbZJfSnCc6GdswSu/XJGQ2INLep3XbpaqNaoVmQ2jaQN55g+brS1LOGTV4jRM/ 4qsZFz2NRwRuGO+5UpECKFhtQZAtAAX2VaduvLuBHe4lAaiEQwOGoeP4bjfB9dJxGJF0 J+sASM2vlTgJnFvLK7hXAC7PGj11Q/MwAy7VrX00B2wlvF5kQRILPhwWLFOJ6/3TdFr1 Fss77rxl3IuAoN5butwmM+65qCPB9dczMM4bjnMOQu8hyjtr+QRN9IPfI/ImgFs+mkUn RZGg== X-Forwarded-Encrypted: i=1; AJvYcCUVcbRP9QfJHJotYHzvHQpv6EWUQoF4MZ8rKKioMqgnJpjaIZ4R8vLXQvoKGVEGYPz4RushQJ6kXJVdgGNtTc3f8Zw1UlN4UTAC6I12 X-Gm-Message-State: AOJu0YyfsxW/cZKDxQF/kCn74F/qOfrbA9lGNKzfU52WOLIlb1lvSG7r UvHR2WhhHUlNM7FJtUbQByOl2tIVqfA/YjvaaAMHD/5gKy6QHqys1e5ThZ1QlRQ+TcqQ4VrWd04 oCRcMFhsJmUeiDoY3Swgazwpc8ba9S1cq X-Google-Smtp-Source: AGHT+IFUf5YzuJwzpEShjynWgw/C9/uSnGEaRv+XPohYKjeV9txCgeNvcdN/jTaJ2UwL8BX7mNqu8FWA8W126etv/B8= X-Received: by 2002:a2e:1319:0:b0:2e6:be3c:9d37 with SMTP id 38308e7fff4ca-2e6be3ce4d9mr123752651fa.14.1716185144195; Sun, 19 May 2024 23:05:44 -0700 (PDT) MIME-Version: 1.0 References: <20240516205458.ohvlzis5b5tvejru@awork3.anarazel.de> In-Reply-To: From: John Naylor Date: Mon, 20 May 2024 13:05:32 +0700 Message-ID: Subject: Re: Lowering the minimum value for maintenance_work_mem To: Masahiko Sawada Cc: Andres Freund , pgsql-hackers@postgresql.org, John Naylor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, May 20, 2024 at 11:59=E2=80=AFAM Masahiko Sawada wrote: > > On Fri, May 17, 2024 at 5:55=E2=80=AFAM Andres Freund wrote: > > I think we should consider lowering the minimum setting of > > maintenance_work_mem to the minimum of work_mem. > > +1 for lowering the minimum value of maintenance_work_mem. I've faced > the same situation. > > Even if a shared tidstore is empty, TidStoreMemoryUsage() returns > 256kB because it's the minimum segment size of DSA, i.e. > DSA_MIN_SEGMENT_SIZE. So we can lower the minimum maintenance_work_mem > down to 256kB, from a vacuum perspective. I've verified 256kB works with both local and shared memory with the below commands, and 200k records are enough to cause a second round of index cleanup. I don't think we can go much smaller than that without changing how we size the blocks in the node slab contexts (or when they're created), which is currently somewhat arbitrary. That'll need some thought, at least when we get a use case with work_mem as the limit. set maintenance_work_mem =3D '256kB'; drop table if exists test; create unlogged table test (a int) with (autovacuum_enabled=3Dfalse); insert into test (a) select i from generate_series(1,200_000) i; create index on test (a); --create index on test (a); -- toggle for parallel vacuum delete from test; vacuum (verbose) test; Side note: I'm confused why shared memory works at all in this case, since it failed for 1MB init segments until we allowed callers to specify a smaller init size. The overhead for DSA seems to be significant for small sizes, as evidenced from the amount of usable memory: shared: INFO: finished vacuuming "john.public.test": index scans: 56 local: INFO: finished vacuuming "john.public.test": index scans: 2