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 1t6BFU-00BBrQ-Mp for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 16:08:44 +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 1t6BFS-00AQbm-Tp for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 16:08:43 +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 1t6BFS-00AQbb-Ic for pgsql-general@lists.postgresql.org; Wed, 30 Oct 2024 16:08:42 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t6BFP-003qXZ-SL for pgsql-general@postgresql.org; Wed, 30 Oct 2024 16:08:42 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-539f58c68c5so11387774e87.3 for ; Wed, 30 Oct 2024 09:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seiler-us.20230601.gappssmtp.com; s=20230601; t=1730304519; x=1730909319; 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=ZEMnudOpCbedSVNkQka7rWSXROT2C3McKhXLhrWLBQw=; b=wDgwWKFFjFsytGYRZ/YkPFJC6rsXUIY1RFAQtdJSP1lYQxSH1zfZ8mT8uqIL8gXf/G GDF6N7ej21+FVIrKdlJq6RncxIS2oUI71jFw4EQm8FgsLNj0ho98LI3I47gBLtUSmwBL fFI7lau0tW9GxOqjwvIPR5bK76YmscdM8Rllb+q9zvjtPXITkRbV5++ILETiv0hsFL9J RHPuvW3acTWDKKHyZDJ2LYp4UCFIoRhVqDzYlp6ItJnnrEurJb5ixSWkmJRT3Ha1QHED CjGQuw9elGbMh808DC/zoUbiCS0kbR5cYIi1ZLjiw4kUhQMnTWVIZPVptF+7uVAJpTrk TOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730304519; x=1730909319; 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=ZEMnudOpCbedSVNkQka7rWSXROT2C3McKhXLhrWLBQw=; b=ENaHDd780H/OfvqQ09UE18ZWYvo4lCDXaiLCnaP9ldXhpRuBTlOJxZKsd4PY4z22al ssx8q5HOFUk2jdN/BZh4B/6onaXJOqMlzLW1q+VGW1cLoj42Bn2fYWHQeYYUDP8Ulf5T t8NtW0gwH3z8/viNkXa2FacwS6XyIFOEpX/5rV6k8g06fo14Fb8Gm0O6rY24jiR7QceO Pls2zIcvu+JZpqwQG73RzIPXnxrgP51Jae6PpuD5dVpAdqE5bMTHGbhLBoNa9OD82SOw 1+L/juGLbY51Pbvq59hfB76BV+q8gFbOS1EwWcpqYrH7i/YI3FQBSj1YVBeiDlo9XdAd DzPg== X-Gm-Message-State: AOJu0YzvH86s4B9Cl3Km90y5WxbNzeghtz4Yvx2gkePPr7E/xdKDzMDI +5q05lWVUQt1k4TaK00I2g78r3TZ92WgmBithvE4koVPeb2mV7DtOqtWz2uF4vyxSPAJt1nnVEi ouAD2wRDovLSBu5UPiDcB66dzLSJwJ4bCgOS3EA== X-Google-Smtp-Source: AGHT+IF2bJpwEvea0lKgXlO4hn1yTG4n5ZF/H6a7DfDoKE3ir09NHRTKsA+6+tM8aOft6W8w0ti+XnuTcJMJXwrP1xI= X-Received: by 2002:a05:6512:a92:b0:536:53e3:feae with SMTP id 2adb3069b0e04-53b348ba12cmr13278406e87.11.1730304518608; Wed, 30 Oct 2024 09:08:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Don Seiler Date: Wed, 30 Oct 2024 11:08:27 -0500 Message-ID: Subject: Re: Index Partition Size Double of its Table Partition? To: Peter Geoghegan Cc: Postgres General Content-Type: multipart/alternative; boundary="0000000000002f85c30625b3ead1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002f85c30625b3ead1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 30, 2024 at 10:45=E2=80=AFAM Peter Geoghegan wrote= : > > It sounds like you have no updates and deletes. Right? So the only > thing that could be different is the way that the pages are being > split (aside from variations in the width of index tuples, which seems > highly unlikely to be the only factor). > Correct, the table only sees inserts as far as DML goes. > The heuristics used to trigger the relevant behavior are fairly > conservative. I wonder if we should be more aggressive about it. > > > I should have also included that this is on PG 15 (currently 15.8 but w= e > created the indexes when it was still 15.7) on Ubuntu 22.04 LTS. > > That shouldn't matter, as far as this theory of mine is concerned. > Anything after 12 could be affected by the issue I'm thinking of. > Why would last month's index be so much smaller? Both indexes were created using CONCURRENTLY, as each was created during its month when we started testing. The September index was created toward the end of the month (Sep 26), whereas the October one was created Oct 1. Both table partitions are getting regularly autovacuum/autoanalyze work. Don. --=20 Don Seiler www.seiler.us --0000000000002f85c30625b3ead1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 30, 2024 at 10:45=E2=80=AFAM Peter Geoghegan <pg@bowt.ie> wrote:

It sounds like you have no updates and deletes. Right? So the only
thing that could be different is the way that the pages are being
split (aside from variations in the width of index tuples, which seems
highly unlikely to be the only factor).

Correct, the table only sees inserts as far as DML goes.
=C2= =A0
The heuristics used to trigger the relevant behavior are fairly
conservative. I wonder if we should be more aggressive about it.

> I should have also included that this is on PG 15 (currently 15.8 but = we created the indexes when it was still 15.7) on Ubuntu 22.04 LTS.

That shouldn't matter, as far as this theory of mine is concerned.
Anything after 12 could be affected by the issue I'm thinking of.

Why would last month's index be so much = smaller?

Both indexes were created using CONCURREN= TLY, as each was created during its month when we started testing. The Sept= ember index was created toward the end of the month (Sep 26), whereas the O= ctober one was created Oct 1.=C2=A0 Both table partitions are getting regul= arly autovacuum/autoanalyze work.

Don.
--
Don Seiler
www.seiler.us
--0000000000002f85c30625b3ead1--