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 1t6Giv-00Bnrc-CA for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 21:59: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 1t6Git-00CvVu-9t for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 21:59: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 1t6Gis-00CvVl-Qo for pgsql-general@lists.postgresql.org; Wed, 30 Oct 2024 21:59:27 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t6Gim-003t81-C5 for pgsql-general@postgresql.org; Wed, 30 Oct 2024 21:59:26 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-28896d9d9deso195796fac.2 for ; Wed, 30 Oct 2024 14:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730325558; x=1730930358; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gKVk97Y00mrC4j/4YO9ZUH/cjB8zDICsG7HRWshKLw8=; b=cLUlu1k7mMhP8E0cFvTB0uwxAca0kFLkeYLPMeA0o8bdFXEPj8K3JoDaw++iik79bn Pf1KjbeK2oY522WFD2RIYeLMYDkcHrR3xSIl9BLIobE8gJqatqwRoNUSsgLiNL4NT1MA ZQvnXiYfsYaD7W6vtbH2Ghvro7gi0UZQCsAtKsfdjzvFARYvuysBLozop1TKxHXP7bJs SJv5nn6bRUzK0D6ZLHMZSBveKbXMFYIkdsWuEq5MDie51CHDZRH7pOpDZss2dugptcYI O5W+ageAqtL4GusTsRerKljwwAQwO0OfaFfUXav+DUEBO6f2MtgfRTX80RiowUDoMUvf EIiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730325558; x=1730930358; h=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=gKVk97Y00mrC4j/4YO9ZUH/cjB8zDICsG7HRWshKLw8=; b=iDul7iTNQRFAuNacg1wx442BLScpBVociWMwm/0ldjj4URvTknKQGu+up5x2Ib55IF B9Y7Jn8bSkeFIFrsKKOiYGNYPqbV+U5qn6GLgcZNrbRWkbpuM1ZmqdhvGbtkRy0tbCJi q0573LnMs0QfcuauSd4ujwmLruLaLWh7YKHI2m+FBNMaTszC/QFkEZ6JUzRRn1t2OPUA wapgSMyCyPofY+ZPEj8bu3x4/ObQ8KZ0sWUedqo3OLQjiYM070A9HCzjbdB/Kbld42Dw QIT85LgPxIZGnBuJA6BWdNDRNzPDVSHKXIZ4ochXKP25Gw+kjrzmlXM240GbDqIZjyAO yzgw== X-Forwarded-Encrypted: i=1; AJvYcCXt1izyt5AnvzyR+I6j8DY5UJ6BW7KKoMSi+6OgKtGGWiYamJqxFQiO7Yg5aF3pkRv15WiyKc3AvpPIOQX/@postgresql.org X-Gm-Message-State: AOJu0YzBBrVv9zlQAgJ0jM8O7O79q54UfWJbIXZomwzH1pSDbZ21Ft7/ QIWQV8QkvZoyQRr3hq/xX3KiDnwaXtSKklvwf0aW2kvA5m5tlVHpQjlmp+w8WKDAme6wKnoSloH LOT9YD4GmWGnTQ/S62FTfV7E+b5B1qA== X-Google-Smtp-Source: AGHT+IFY+Vtz8QOw4ZE+nIorOD79hq/AJ5t7xwMpZNtgh6GHKLOej7j3B847d0PgDBIGFOqLwPCvTNXGOR/P5YqR59Q= X-Received: by 2002:a05:6871:331d:b0:278:4f7:6058 with SMTP id 586e51a60fabf-294648184c5mr5019184fac.28.1730325558010; Wed, 30 Oct 2024 14:59:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Mullineux Date: Wed, 30 Oct 2024 21:59:07 +0000 Message-ID: Subject: Re: Index Partition Size Double of its Table Partition? To: Don Seiler Cc: Peter Geoghegan , Postgres General Content-Type: multipart/alternative; boundary="0000000000003b2c5c0625b8d02b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003b2c5c0625b8d02b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you able to cluster the table ? The idea is that rows ordered in the same way as the index might reduce it's size ? On Wed, 30 Oct 2024, 16:29 Don Seiler, wrote: > On Wed, Oct 30, 2024 at 11:23=E2=80=AFAM Peter Geoghegan wro= te: > >> >> If a substantial amount of the index was written by CREATE INDEX (and >> not by retail inserts) then my theory is unlikely to be correct. It >> could just be that you managed to absorb most inserts in one >> partition, but not in the other. That's probably possible when there >> are only relatively small differences in the number of inserts that >> need to use of the space left behind by fillfactor in each case. In >> general page splits tend to come in distinct "waves" after CREATE >> INDEX is run. >> > > What do you mean by "absorb" the inserts? > > It sounds like the answer will be "No", but: Would rebuilding the index > after the month-end (when inserts have stopped on this partition) change > anything? > > Don. > -- > Don Seiler > www.seiler.us > --0000000000003b2c5c0625b8d02b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Are you able to cluster the table ? The idea is that rows or= dered in the same way=C2=A0 as the index might reduce it's size ?


On Wed= , 30 Oct 2024, 16:29 Don Seiler, <don@s= eiler.us> wrote:
On W= ed, Oct 30, 2024 at 11:23=E2=80=AFAM Peter Geoghegan <pg@bowt.ie> wrote:<= br>

If a substantial amount of the index was written by CREATE INDEX (and
not by retail inserts) then my theory is unlikely to be correct. It
could just be that you managed to absorb most inserts in one
partition, but not in the other. That's probably possible when there are only relatively small differences in the number of inserts that
need to use of the space left behind by fillfactor in each case. In
general page splits tend to come in distinct "waves" after CREATE=
INDEX is run.

What do you mean by "absorb&quo= t; the inserts?

It sounds like the answer will= be "No", but: Would rebuilding the index after the month-end (wh= en inserts have stopped on this partition) change anything?

<= /div>
Don.
--
Don Seil= er
www.seiler.us
--0000000000003b2c5c0625b8d02b--