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 1t6BTR-00BDC1-Qk for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 16:23:09 +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 1t6BTP-00AZ28-M8 for pgsql-general@arkaria.postgresql.org; Wed, 30 Oct 2024 16:23:08 +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 1t6BTP-00AZ20-Ac for pgsql-general@lists.postgresql.org; Wed, 30 Oct 2024 16:23:07 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t6BTN-003qdd-9o for pgsql-general@postgresql.org; Wed, 30 Oct 2024 16:23:06 +0000 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-37d447de11dso55087f8f.1 for ; Wed, 30 Oct 2024 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1730305384; x=1730910184; 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=NBzc3r8nFgecXJYOC7QzrZx8Xnpkgx5pRYqA6YFUyeg=; b=XtgkeT/8FLyT4jQ6Q4KjKbJ/SEtv64aCsm0kMS77HsdHqGaJCxc9iRsJJahJ9/1YM1 B7ZRn61sBbCBJOpHJH3qckFFW2hmVi45P0GW0cIt32am8/aRaZn9O43hrveSs09bwBdf VpMWbQ5oUg8n395Qz8a9U18vxRBUZsE+nPlCoQJRt17I1zEbKgp29mBAb1/xkTQtcM6k 0+PVRDPHcvVvMVKR48Ro5lNojocsA22EptWn9Nop6xWxYrxYAuyDb+Uge7uNhH/kDREI Ku8j9hNPuUCZ1JsR3b+3in5tfXVM/O7XhhtN2xZ7snsIaCSy8kNQAF+8AYqrr70tLuFw Xztw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730305384; x=1730910184; 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=NBzc3r8nFgecXJYOC7QzrZx8Xnpkgx5pRYqA6YFUyeg=; b=mwaTj/VhFAJ47mAOWQm8ioM7XlDxaGG/feDXQ0G24LU0ZeSDW6+/OpKpXS4SZpNRSc i5dkes90FWrvF6HkwWW4IQNTLmZOLL3/7PSSBG7VQeuhNDSg5l4SvFjbgTvGJws9vMxM EkKeVBQwzgDJuGQ+b19yHJ6joJ9RKBoRVqz5VfFmmG/bQHdUkW/PtxJCTtN3Zubz3mEN 52mvrDFJIgokUBqeXBHj+OF64CED7DX0n4oMnPS9DWug7yiqbv74KZRSj8bTEXpKC+Wp eUVNZWBoANu4HP2Az5M8kb+w/eGMrZ7OKhqf+Kx+tPkuMrLrMSBlVFl6JNvqBRmmb6FH V3cw== X-Gm-Message-State: AOJu0Yxb/DhP+x49IsHgK3J1sGM81AADlDScZKGU+afaj8wjxVdnxcbX Ua+/1Alc+qB8JeSS5wVH5ez1h5VBtMWqrZkUuHT/v5VW5xmtLPwotBxVL1lXecCTUoRkIm14heT jXOV+h89ssnEGa7/EA6ig3poFYNDPFxtqqEhiMcLi/hDo5/Uo X-Google-Smtp-Source: AGHT+IG8ySGYiSnQsFszqItD+hDP/DVf9EZbAa0nARB+HEWHkKi0dXrR7CBrR+HH7VP3a3gcy4nvUHfOI/QkQ/k4OXM= X-Received: by 2002:a05:6000:144e:b0:37d:3742:a5a7 with SMTP id ffacd0b85a97d-381be7d9095mr142924f8f.33.1730305383598; Wed, 30 Oct 2024 09:23:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Geoghegan Date: Wed, 30 Oct 2024 12:22:37 -0400 Message-ID: Subject: Re: Index Partition Size Double of its Table Partition? To: Don Seiler Cc: Postgres General 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 Wed, Oct 30, 2024 at 12:08=E2=80=AFPM Don Seiler wrote: > Why would last month's index be so much smaller? Because the split heuristics worked as designed there. That's the theory, at least. > Both indexes were created using CONCURRENTLY, as each was created during = its month when we started testing. The September index was created toward t= he end of the month (Sep 26), whereas the October one was created Oct 1. B= oth table partitions are getting regularly autovacuum/autoanalyze work. 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. --=20 Peter Geoghegan