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.96) (envelope-from ) id 1wFEoT-004sHp-2t for pgsql-performance@arkaria.postgresql.org; Tue, 21 Apr 2026 17:23:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFEoS-009sYA-3D for pgsql-performance@arkaria.postgresql.org; Tue, 21 Apr 2026 17:23:05 +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.96) (envelope-from ) id 1wFEoS-009sXR-21 for pgsql-performance@lists.postgresql.org; Tue, 21 Apr 2026 17:23:04 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wFEoQ-00000002Khl-1q27 for pgsql-performance@lists.postgresql.org; Tue, 21 Apr 2026 17:23:04 +0000 Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-50d7c12e48eso46847501cf.1 for ; Tue, 21 Apr 2026 10:23:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776792180; cv=none; d=google.com; s=arc-20240605; b=WjZFHkVfwIHsqD4jT29csX5ZvWRDt98N67qGPhQ+rDjmncTNWQvZoiASBeOQNZn4y/ RrMLHgvavtwI41+XMBw7DWxsIeVoiDL0sMW87cVPga3mlk/8jRaNbzApJxov//cInC6D XIs+Beo4Z7EZO20Y3VQ/iBWzYXuCSYGYjC2foW6tNOK3LhE5L+VAUIMw+0hZfpnFWrKT F11UNveUQ00KJlhgMTXX4TPD3K5kbGHhBxS64pyoz2+cY2j8BErr563XvY0FkQUTNdPW HIVJo4jkW8STZnCIlPA6BkHt/QCELLZT50mLFtNP9qjHdKidk3NKTB+/k8C7GfCua2XI 1iuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=JSZG4RD2MtwONOg3UGUbXLpe3GdVRZxmqebo3OSZ1B0=; fh=z/JQ2tSXVGoYKKvtD/yyy3g3xqdpsR82Ngoo7GcsvL4=; b=aJHvh6r6AJNzshI6nYgwc/jsIil52D2LQ2l2Xk7jw7nnPDM3qzBLFu/IDRP/pZ8ePg OTMC2QMgb1gQiCAc1x4RHe3RjWKgmC9QT5eSaquBvMPt0QnPiz4NS2BVbdjk7FVwyiPu scRMuE+zhr0uVpZJNKkQE4Gp/O7d5ncqGxvxgNUN5aIj5uDS9A00SCf4SZbECtHUW1/C Mv9PMPAwtElPLN7DE5/Z8S7xCgyMQYm3Y6d5vzE+dC7cIOLU1+2efSXg1RhKyEhlnUQT SMdb+x8x+xhQ9U7TZC4pM5D0SCJN8uaJJuxxmL3ykuKd4gsK0H2VfRC2HVmI2IAbmkzX rnEA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776792180; x=1777396980; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=JSZG4RD2MtwONOg3UGUbXLpe3GdVRZxmqebo3OSZ1B0=; b=DPLikg0V0pE1fUo3xxAH+jmv+FjAAYNam8afVm/v9rm1l+PPK/DnHfrve5UYb/x+rI Gp/SH5ooZxk9aKIzhu2rEnJCAnXnBHnqDLna2tBsY0JzTNXuv+zyBiZAklwlkqoiH0pY hVAhWmGMDFQ81mY0h7JaAKSaljKO2uizXXqQw5Pg15X8llYuRRRY57AYygWEodkcUV2n mU5BcXAU3zAEKv+LKNA6LM1QLAGSI1wmFb4CYfVONl8Yu6w73FVaCWbME4dYQ7f90gO2 RFMLkKijzNvExmkfK0wTAUqXjY2f5K1dyTH8OFheH0ZFoIB4T1Gkamot3c0XuH1OzUKA 8O2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776792180; x=1777396980; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JSZG4RD2MtwONOg3UGUbXLpe3GdVRZxmqebo3OSZ1B0=; b=fsCUfts24lSiwgx6qCOt0NIqeTv6qQdjRvkCXI/0bd81HM1b34PTx6pa3+8BwWZ7V/ +GChGOGIaaEOHaMaxwDxLxkivoNnmTosvPDdTeakCmd4WvqwUBsu3zuGf6Y0IZlBu8hh 3W92RnOlWiQw0v2v2H9ZGGifKjkIkkD7aImUO1tqtYLHV4O89raJUx7x4q08W9jmh1x5 y5S3Cf6SO1cMrOxHNVmtFwvt+dh6kEKbzpyhsNmhSgxwIKO+NWo/Fl3STeCzhrpGmuYm KlErHYVer8VVPEfSUdtAP4kmQvk+xbaRqgcm4anoD9fCa+nwcenPBNkIFlTi0WDjqV16 hxXw== X-Gm-Message-State: AOJu0YyVXMwqPN9DLJTsoPZK9LA9hYo4ThOD+zLnxQzggoQvFGBFtQmb bKlmV2QR54WIYzQPcLUlj/IOAzVnbcSrq3RwRi4tJC7CyccZJ+9hAxbr+o8HbHxwom5+l+g5jtC SrV+nJJd5+qSxoPwDz8D+wBrCQVGOzYtZLk6U X-Gm-Gg: AeBDietQqP89MjoAAjwrD26i9JAV5oBfDaAkBbwXrWxVKl9QGov8MkZQTTzCZHQ/OBK tJ+ugX6unnr50Iuc3eqwFnp11rQhqtFI9g8rrhFZHkcefC7bToIpWNt5H6LxO/wzhWUoqpTo2OI dvMf6S6gOtJB/d+2fVb2hLjrgCCm/aNGHE+1bM0AcDVO0aaPMHJHrI61a3t8uwD8x+UwV4JP/U+ aUj6tJUArZn+ebaTGyt4KSY84bHDS6XI9W7Tvqe5HtZimVgH2TizYcMmI9q9di1NaVAtD0Y5P+I 6LsEENCN+/+f3wDA9rV24v7QHfNbyKTgWg6ejpIHopA6+p5Zv4KugGWAdmD5nDo1WG98MJRxA/W EhP/kWwNy X-Received: by 2002:ac8:7f55:0:b0:4ee:1bdb:a547 with SMTP id d75a77b69052e-50e3664bc7cmr256018611cf.14.1776792179837; Tue, 21 Apr 2026 10:22:59 -0700 (PDT) MIME-Version: 1.0 From: Merlin Moncure Date: Tue, 21 Apr 2026 11:22:45 -0600 X-Gm-Features: AQROBzAh8QvnYJTgibkCySFd7Vq4tkGf6vDYxQl05SjOiHPWNigPKOVJ0nzC_Ik Message-ID: Subject: feature request: index supported REINDEX for partial indexes on needle/haystack tables To: pgsql-performance@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000b81188064ffbaad3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b81188064ffbaad3 Content-Type: text/plain; charset="UTF-8" Suppose you have an index: CREATE INDEX ON huge_table WHERE something_transient; ...where something_transient represents a small amount records (the needle) at any point in time, but touches many records up to the next REINDEX. This is a common pattern in queue type processing tables. The basic issue here is index bloat, which is a well understood problem. However, there's an opportunity to have the index support its own rebuild, since it can limit the number of records that need to be scanned. If "something_transient" represents zero or near zero records relative to the table's size, the REINDEX ought to be quite fast...almost a "TRUNCATE INDEX" if the something_transient set is empty. merlin --000000000000b81188064ffbaad3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Suppose you have an index:

CREATE INDEX= ON huge_table WHERE something_transient;

...where= something_transient represents a small amount records (the needle) at any = point in time, but touches many records up to the next REINDEX.=C2=A0 This = is a common pattern in queue type processing tables.

The basic issue here is index bloat, which is a well understood problem.= =C2=A0 =C2=A0However, there's an opportunity to have the index support = its own rebuild, since it can limit the number=C2=A0of records=C2=A0that ne= ed to be scanned. If=C2=A0"something_transient" represents zero o= r near zero records relative to the table's size, the REINDEX ought to = be quite fast...almost a "TRUNCATE INDEX" if the something_transi= ent set is empty.=C2=A0

merlin

--000000000000b81188064ffbaad3--