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 1lWNJQ-0003SN-4y for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Apr 2021 17:58:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lWNJP-0001U4-1f for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Apr 2021 17:58:55 +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 1lWNJO-0001Tx-NB for pgsql-hackers@lists.postgresql.org; Tue, 13 Apr 2021 17:58:54 +0000 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lWNJL-0007Cm-I2 for pgsql-hackers@lists.postgresql.org; Tue, 13 Apr 2021 17:58:53 +0000 Received: by mail-il1-x131.google.com with SMTP id 7so13167842ilz.0 for ; Tue, 13 Apr 2021 10:58:51 -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:mime-version:content-disposition :in-reply-to:user-agent; bh=BSsawmPmnGzPEjKYH/bzN1qVbYHilSxhPrGyimVHQaI=; b=y5ryTjp5s+A4SpgJ7alMCowhOWfT8FGKYrAMv1NWibjY+hcZSrAI5nz0sDa2UDmmO/ JvdscwiVyEaaWzekw1t2BG9NT8rv1W9E1TRLc1mkgNyh6TO+CjJbRFtF9IitO/xWdegR TnZhgi18vOxXdNCOrePPLLBg2tu0sXRC2dC9u/xmwBOr411FHWDoLNH2mkF+kx/u+/a5 hM6uVutMIgpJEuCYjJ7/71trOZd3ZzqZRMg64828HHKX90uDTyb7w6cS6F2EhlTWrcUY QOOQ/R0WZ33wPRz++4oPVQ4ppE3r6zw44eWHi2zefPdP+rywuJOloKWmXF1HNSOUsbR1 4UAA== 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:mime-version :content-disposition:in-reply-to:user-agent; bh=BSsawmPmnGzPEjKYH/bzN1qVbYHilSxhPrGyimVHQaI=; b=qf69lDFeICWv4M66KTxRZ9Gm+yV3xU0QC7CGWMcgs7zZB6hdXCT+js/Is7ldUIV405 OWOefRzQFm85qXWSCMT+Z/67wwbcBNcJTwneBerrp4YfqOlRaVV7bZoxjsdhRkwdxwr8 dAd3Mk6+ve0MA9aDgzTTnsSOmHig9ALp4XhqvQPoYfg2IwsIyNhV4PfuQss5vXLBg10R 4HTx+Xs03m0tf3Ku5GLVgi7ajaPN4CLd7vAtGSgje4I51552iel300guEhrvAviOpb/l RUkjVxXLoVDDrBxxFJ1tmLwVQ/G+5f+fIWG03ctqrfnAC+LpiBM1DgHkHOVh5f+gkqnz 7ksw== X-Gm-Message-State: AOAM5328z/0+Eh3b3OTHJvGpZ5t0Mv2zxrQmwN5GdxZkLsBbppHSgrFF egeC8x69EQD/g6r7PiEmYsCSTg== X-Google-Smtp-Source: ABdhPJwkvVozMRw3E7JLiXZbtpRF8+l7Qiurjr6Bh3oKkk0q/ueJyswXoooMWmpGEeK2y/HvGlmvEw== X-Received: by 2002:a05:6e02:1a65:: with SMTP id w5mr28654257ilv.5.1618336730706; Tue, 13 Apr 2021 10:58:50 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l1sm7103425ioj.52.2021.04.13.10.58.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Apr 2021 10:58:50 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 094D48008D1; Tue, 13 Apr 2021 12:58:48 -0500 (CDT) Date: Tue, 13 Apr 2021 12:58:48 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Amit Langote , pgsql-hackers@lists.postgresql.org Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210413175848.GH6091@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210410191326.GZ6592@telsasoft.com> 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 Sat, Apr 10, 2021 at 01:42:26PM -0500, 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 ... > > If it *implies* the partition constraint, then it's at least as tight (and > maybe tighter), yes ? > > I think you're concerned with the case that someone has a partition with > "tight" bounds like (a>=200 and a<300) and a check constraint that's "less > tight" like (a>=100 AND a<400). In that case, the loose check constraint > doesn't imply the tighter partition constraint, so your patch would add a > non-redundant constraint. > > I'm interested in the case that someone has a check constraint that almost but > not exactly matches the partition constraint, like (a<300 AND a>=200). In that > case, your patch adds a redundant constraint. > > I wrote a patch which seems to effect my preferred behavior - please check. On Sat, Apr 10, 2021 at 02:13:26PM -0500, Justin Pryzby wrote: > I suppose the docs should be updated for the exact behavior, maybe even without > this patch: > > |A CHECK constraint > |that duplicates the partition constraint is added to the partition. I added this as an Opened Item, since it affects user-visible behavior: whether or not a redundant, non-equal constraint is added. -- Justin