Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lO2p7-0002mF-Lk for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:29:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lO2p6-0005o7-Hz for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Mar 2021 18:29:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lO2p6-0005o0-BB for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:29:12 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lO2oz-0007nM-Hi for pgsql-hackers@lists.postgresql.org; Sun, 21 Mar 2021 18:29:11 +0000 Received: by mail-io1-xd35.google.com with SMTP id k8so11626542iop.12 for ; Sun, 21 Mar 2021 11:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gDVjz6XthQDVDCf1ypIUunbhGedgBdRJDGfKNMrR02o=; b=uTR8AeSCH3vFuOJZ6Ff3gakwl5b/DSgbCs2BJQ1BET8rUes4UMQ0DZIFdoBGkwBSND mZ/wB7Pa1r2w46RCVLg2aRzxpe2ApMWIYdyIZ9m7CsUvuJS7KoV5jN/xZCZWN2oBPp9I /E3XMNOvUx3D7PQ9oFXspcg9ZLkvaVjh57PrV4B7app1esczPbllFK2f+Ucz7yP2MZn3 OyHgFNAe7wRzUz2L+bPjLYixlouJPhkl5mMOY5PaB4RFwdadR0TPimai/SiKpeoMjpza Fvv2muFsrEAGoGVrikXjkP0Np1a5ZpvBbQGabpnRZJTnf7lmIgJMP1lwQ5xwPB5qFoMW Lzow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gDVjz6XthQDVDCf1ypIUunbhGedgBdRJDGfKNMrR02o=; b=IAcsfhVAMErGofcvJfm4mW/u72RZ7a86tPgT0oeFwWiBD73eceiaPok02ojlyCN6+P HTYnLWRb5iMWxh5InD3VPksG7Hn0NDjff93eLmIe8IoMqXbKohLeQvQXRhMCwSHTqJrE tfQZUwcckUqLodAR4T5aaukAcfdDYXBNv+clqgY1mXKTxWYtZSGVoBE72U2rTI6W8cQ0 uvzhGcpwvDU36obFs9HGYSBUAOeH/cMJlOJb/egZ83hmkssd+nIVUCpdCs4TUwcKoecL u8WZW8KLZC/1stjdlIe5bfullpaUpREYjXvH/b9yY3xfJOb22s8q6ID8OtPr310rBo9t k1gg== X-Gm-Message-State: AOAM531rHd8p4HTsIBIDEblkxLRqYj5VvepOBFqh/iHgVOMwbCTI7zm6 zJx71iXTAXZBTRtlukDt6JBzeA== X-Google-Smtp-Source: ABdhPJy+ORa3Eqe6a+iY2TghzHPyKoIapeoi6XynX4bauaLwnxNCg9QGGT/D+Rn8x+UmeCaUkMsLEw== X-Received: by 2002:a02:a691:: with SMTP id j17mr8572966jam.14.1616351344989; Sun, 21 Mar 2021 11:29:04 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o23sm6291381ioo.24.2021.03.21.11.29.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Mar 2021 11:29:04 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 5E33A8010CC; Sun, 21 Mar 2021 13:29:03 -0500 (CDT) Date: Sun, 21 Mar 2021 13:29:03 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Amit Langote , pgsql-hackers@lists.postgresql.org Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210321182903.GD11765@telsasoft.com> References: <20210321181420.GC11765@telsasoft.com> <20210321182200.GA3837@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210321182200.GA3837@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Mar 21, 2021 at 03:22:00PM -0300, Alvaro Herrera wrote: > On 2021-Mar-21, Justin Pryzby wrote: > > > On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote: > > > > But note that it doesn't check if an existing constraint "implies" the new > > > > constraint - maybe it should. > > > > > > Hm, I'm not sure I want to do that, because that means that if I later > > > have to attach the partition again with the same partition bounds, then > > > I might have to incur a scan to recheck the constraint. I think we want > > > to make the new constraint be as tight as possible ... > > > > The ATTACH PARTITION checks if any existing constraint impilies the (proposed) > > partition bounds, not just if constraints are equal. So I'm suggesting to do > > the same here. > > So if we do that on DETACH, what would happen on ATTACH? Do you mean what happens to the constraint that was already there ? Nothing, since it's not ours to mess with. Checking ImpliedBy() rather than equal() doesn't change that. I proposed this a few years ago for DETACH (without concurrently), specifically to avoid the partition scans. https://www.postgresql.org/message-id/20180601221428.GU5164@telsasoft.com |The docs say: if detaching/re-attach a partition, should first ADD CHECK to |avoid a slow ATTACH operation. Perhaps DETACHing a partition could |implicitly CREATE a constraint which is usable when reATTACHing? -- Justin