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 1uNs73-00AvNf-6E for pgsql-general@arkaria.postgresql.org; Sat, 07 Jun 2025 11:53:25 +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 1uNs6z-00CFfz-67 for pgsql-general@arkaria.postgresql.org; Sat, 07 Jun 2025 11:53:21 +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 1uNs6y-00CFfr-QC for pgsql-general@lists.postgresql.org; Sat, 07 Jun 2025 11:53:21 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uNs6x-000hvC-17 for pgsql-general@lists.postgresql.org; Sat, 07 Jun 2025 11:53:20 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-607cc1a2bd8so408025a12.2 for ; Sat, 07 Jun 2025 04:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1749297197; x=1749901997; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=SdE1PkDrNymVRibPF2DNzjW6/dTeFaT7FL/OWQ4QvE0=; b=hWnwHsjENWvImwZBF6SuaZQR+nwQh6Qt9WsBILC70tcYZ24tT2YSxWBNthc7TUuUVD epI/U1YvMhH2VFqbLrHaAnwF/cgPkxSsCjI3XnXsxXQqM04gMYWkliqJUhp5nE6cgwg/ gaTnGnrubk0HR8iMPGImHt1Gjriut5dbRKuzMuDc8RvEvx6diWIEy0IW0tIAv+aT7dT0 kw5RVbr2p0g0RPSCe2JUDyXIK/7AwjtVz7fNSWLWGZOBJO7H4N3HPckrNlV6CfLKU1xq JEPN28NCny7vA6JA9KQnJGJrQbml6DDgWSNvn7Z+9cfReKp4sTWGJmmf9ycYY1Me3JTR GKSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749297197; x=1749901997; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SdE1PkDrNymVRibPF2DNzjW6/dTeFaT7FL/OWQ4QvE0=; b=HQ9NKNi416kdgktb7u1k/Kf/NJIaY1yOrkSipFm6nErmNfHgQpZYH9hV0H7u/hxvv8 EdfvWARksWsPcyPgos4jtm2wCwOS5l3Uuolc9tIpOwla9FdceCvJI+/5LVwypMG6iMkt cwXJIG0719XbTqOr+BYvbcy40DzUvmPG7rUV43nJC1+p+GraIbLa2WckHJGWpG6RuGwj bkQbpMWsRGgY+8afYx7r7qY6vCcignTGJNJiN5s+wkb8+89bRyoFl51oqAneaQqu1jyD TMMvRIgKPxcT6/y5ZE7ih/rOvJU2ogw+VB5XMGjuX4/NnQeIFx+38I45X1hwWoGXNMIl xBRg== X-Forwarded-Encrypted: i=1; AJvYcCXgvu0bpA0vMxHtGKDIdbXAoPo6txPUFOjfqSJgQLRt3DOMdWTaGNXm66sjceX28Eqp/ZCFrow9dtyWsC1y@lists.postgresql.org X-Gm-Message-State: AOJu0YwGFhlphTf3u9exm2jFN4hIpfK1qSo4vHJhurGma9mRGQ9GfWIp 859iFCE7O79+aD0Zw+EGzZg36ludlPE8hrNekhpptNjoxaXLH2JcDmHCCUolpcMoaRs= X-Gm-Gg: ASbGnctVasabr8QroXAK0gJKCveA2BGpAFHAlKWxFT/vVTApLbwmT6xv01yyL4PoifD UAOPU6AHsD1WlQD3WyocLwEqS6A47PcFycJjmvxD1JVKcibQQOzyWHyx4b1rJBGhILnP4AEwAv0 r4G9rNsvhnwpuhuvmDGx9SpFyUid2fg2puDjGFvAvauKpmSvAGvJ2a8WjgzD0DJAOisPPR4q0kQ WInlFkkkdpD7LfqIOg644rtKeMEY+MySzwmpOI7S21ZnM/sWA9YDqikPjAEq9A2beGSZTfH0WWC 938DdfzRGvrQ6pm3O62NEe2MWg8ZD0B+8WdiyxWiOFj/7M06JOlw8yaX0Ee5BY9DYYN/EPr7BGL QbHfSgfBivd42CAGE X-Google-Smtp-Source: AGHT+IGC0Gxk6mI1Sd3Pyb4tO4W+zlIX1Y3mAOOLDtCTFoqixCXBh80KG45hgC5wchxEII2BZIEo2Q== X-Received: by 2002:a17:907:72d2:b0:ade:3ce3:15d1 with SMTP id a640c23a62f3a-ade3ce32d39mr247780466b.27.1749297196318; Sat, 07 Jun 2025 04:53:16 -0700 (PDT) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:260:9dfc:de37:7fa5:32e9:e556]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ade1dc1c725sm261742966b.84.2025.06.07.04.53.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Jun 2025 04:53:15 -0700 (PDT) Message-ID: <84b6da7feb3de406d20a4a0e80954520a6db6b6c.camel@cybertec.at> Subject: Re: Regarding fillfactor use case for only delete ops From: Laurenz Albe To: Ron Johnson Cc: Durgamahesh Manne , pgsql-general Date: Sat, 07 Jun 2025 13:53:14 +0200 In-Reply-To: References: <65a54f809d0339d9d6021c35f7fa14fc20a7f2e6.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2025-06-06 at 09:59 -0400, Ron Johnson wrote: > On Fri, Jun 6, 2025 at 8:57=E2=80=AFAM Laurenz Albe wrote: > > On Fri, 2025-06-06 at 14:10 +0530, Durgamahesh Manne wrote: > > > Can we generate a fill factor for tables that have delete ops ? > > >=20 > > > Does the fill factor really work and help to minimize the bloat for t= ables that have delete ops? > > >=20 > > > I have parent table with weekly partitions So for every week 50 to 60= gb of bloat generates and autovacuum params already in place for child tab= les=C2=A0 > >=20 > > Nothing can ever avoid bloat caused by DELETE, except partitioning in a > > way that you can drop a partition rather than running DELETE. >=20 > Isn't the fill factor aimed at reducing bloat during updates of HOT table= s? Yes, but not during DELETEs. HOT updates also don't directly avoid bloat on tables; only on indexes. They reduce the bloat on tables inderectly, because the dead tuples can be cleaned up with less effort. Yours, Laurenz Albe