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 1v6Spu-0052E1-M6 for pgsql-admin@arkaria.postgresql.org; Wed, 08 Oct 2025 12:00:02 +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 1v6Sps-009k4w-Bw for pgsql-admin@arkaria.postgresql.org; Wed, 08 Oct 2025 12:00:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v6Sps-009k4j-0S for pgsql-admin@lists.postgresql.org; Wed, 08 Oct 2025 12:00:00 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v6Spq-000fFt-0M for pgsql-admin@postgresql.org; Wed, 08 Oct 2025 12:00:00 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-30ccea94438so4078394fac.2 for ; Wed, 08 Oct 2025 04:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759924798; x=1760529598; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=I9SWZ6lU5EIZkIDStwi1U+G5onlyGDsldphAAH2hVXg=; b=dV9cztxKgAr5mGKdRC3jvIVav8j7vJ3CI40OUTHBqvnzwfHPUidhe3MB0ZVHjQyvrb p8k5/kLPCS0tHyM2ItXwbJdLihQMRoiRNIBtp81p0dthpvxZKqsQCcPmsAgu5ud1pamC D+tA/xxJvRdDNVijyPbb1j2qFq/nHksP/cCSBBLk8fFm/X6nNqK2A3LCFz5o4emZWNWN PTzHP2WUWGl1FL2d0jfopSdm9pTVzLhy2lM+VPTZkul4DAU5WTD8iaXfEAKZz4OC+ftD gHSpdxTS7wVEkpCHe/Xy4+SMWwIh/sLG8/GmaO41ZD2WvnCNyPGgIcVagu/ljy4SGIuF 1crg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759924798; x=1760529598; h=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=I9SWZ6lU5EIZkIDStwi1U+G5onlyGDsldphAAH2hVXg=; b=MxusaUp19XEpeJiMY4QzPQLsJYeSIKkiu/oLVyr5ZVE6exEi/Lpv21PZt+yAYknWsI RDC2PjQTOx9NBxhJ/Vx84Q1Ute7vSfrRAZKr/h8k5WNU7+sQZIZphr8TKZO1XAeD3Fmd kDB6MbEww79BFUGbOxqgAOFOdgD1827jHARFeRpxA5HVNdo3btVEAbs04VzoEp+AM974 fBim3HSA5mjL50ksde2C8s9GEh3yubdtVYvqe5dCsUlEG/EQOtfs5d43/9GBb1HNMyrd zDMbabcyynOE/v162gVxZcd/nh6QoUvcx/4lyIx5qxKueG1LzBoeegQeJUJbObjqvm3F X5GA== X-Gm-Message-State: AOJu0Yys4vIS/H7yl94uc/mMrIxILr9n5LE89TjMqA60sF/37lMFfAlg +roHgBDJvFQvlyhP1sk1iYEMLBgspkoEqaR5mIsdr8KEW+bBEyIM1g3U4LJPGRrQjLeJTmna12y 7ISvQqtA8T2E4aMELOBceSm/uvUAtM/i6v+VK X-Gm-Gg: ASbGncvS4KeyMx1yX+Gz8xn/VSo6hyDKz6G6FvKdPEW+THCxpU3cAR+V0envVWVsEoV 0qx1Zz7umZK89IsWZNb4I2iaN+caJnoAXDNR2ivz3pgh7wCcp5DOom1/ywgO4zJJ3oOjmokx79l Ll3hXPfvKuCW8XKArc/hn3GX0J3z+EirEb8fviSZysQ05NIAqBIY+9OfnAruGUhfvp56p4wl9c4 8uxSN6TE326errS7FluF8nhKn0a5aJIf3PQ/nMHGoc= X-Google-Smtp-Source: AGHT+IEDvd8qciaEODznPZwrIv68c3OCoHKNwFkxy+LWcs/tlx3C3wjl++kIxpkB/7A7KfE/P6r9EE0zOYGQfL0G2zM= X-Received: by 2002:a05:6870:8103:b0:35c:e7a6:3e1b with SMTP id 586e51a60fabf-3c0fac53c07mr1782738fac.35.1759924798061; Wed, 08 Oct 2025 04:59:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 8 Oct 2025 07:59:47 -0400 X-Gm-Features: AS18NWBJBg358KsmWRh1dhvm19kel2oDUjbI-v3v2rgB-3vGHjSYezBjKbbxTmg Message-ID: Subject: Re: Dropping index from large, partitioned table To: pgsql-admin Content-Type: multipart/alternative; boundary="0000000000006b816b0640a46c4a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006b816b0640a46c4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 7, 2025 at 5:01=E2=80=AFPM Matthew Planchard wrote: > I have a very active table with around 1,000 partitions. I would like > to drop a GIN index on one of its columns. > > Unfortunately, this is a top-level index, and so it seems impossible > to drop the indexes on each partition individually, which means a > 'drop index' requires holding an access exclusive lock on the entire > table until the process completes for all children. That process turns > out to be much too slow, since it requires locking one of our most > Too bad there's no ONLY. clause in DROP INDEX. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000006b816b0640a46c4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 7, 2025 at 5:01=E2=80=AFPM Ma= tthew Planchard <msplanchard@gm= ail.com> wrote:
I have a very active ta= ble with around 1,000 partitions. I would like
to drop a GIN index on one of its columns.

Unfortunately, this is a top-level index, and so it seems impossible
to drop the indexes on each partition individually, which means a
'drop index' requires holding an access exclusive lock on the entir= e
table until the process completes for all children. That process turns
out to be much too slow, since it requires locking one of our most

Too bad there's no ONLY. clause in DRO= P INDEX.

-= -
De= ath to <Redacted>, and butter sauce.
Don't boil me, I'm s= till alive.
<Redacted> lobster!
<= /div>
--0000000000006b816b0640a46c4a--