Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gpFjB-0005rU-IV for pgsql-admin@arkaria.postgresql.org; Thu, 31 Jan 2019 17:02:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gpFjA-0001iY-9N for pgsql-admin@arkaria.postgresql.org; Thu, 31 Jan 2019 17:02:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gpFj9-0001Ud-Sk for pgsql-admin@lists.postgresql.org; Thu, 31 Jan 2019 17:02:12 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gpFj5-0003wL-O0 for pgsql-admin@postgresql.org; Thu, 31 Jan 2019 17:02:10 +0000 Received: by mail-ed1-x541.google.com with SMTP id h15so3186521edb.4 for ; Thu, 31 Jan 2019 09:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=86D19f/3WkHWMqdxRBnZVdLUOb0HHXUvi4H9GFBIpFI=; b=BACoR3lWLrT+CyZKq6v5ZPG/LnCgL6pgASSeVUAJPwGqo34sgiIG6bRtxCb5A963NE mStD3egAgBlRTf+s7uW+kgXeosSQyfnt7sbuYPBVHELuoXbWm5qyMfcbJCW6X51lpSyj UgQyRxW75Br49d2b8sAIg4Cz3O8plL869tpNYvqgfkZnE9D57sjn1ljDahEL184jqZ12 Ktcb6qV2KKE2ObwqXO0TzZIDWxDQ78lbcrv+yR7jVU8FWLq8rmtHB4TRhcxurwG7cmXR r4gEnPmlg85Ghe2+ejvUTUNTx+bjAtrOasj7Ft3+wiGH7m/QqtaAEtK46vpcbyg/PeQK Nh0g== 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:content-transfer-encoding:in-reply-to :user-agent; bh=86D19f/3WkHWMqdxRBnZVdLUOb0HHXUvi4H9GFBIpFI=; b=lKm4zhlKQDH4txmq0MyWdsOjhhQMkqQEiKYwdObgRr7ozOoxv8/bF3UTfLFl4LO/jd WekpM7GjMGOVUktXk8dpHbSzsqUJFLbY2ywMk1Jv6X8m3xlR9JSclV8jeTBSwCFr7aY2 yZf/U/G5LyLiAN8pw7Q+WNXQt0meJEEHxWYIIvUCte8fcsESCX51SoKA8ecY/HXEqRCl RZ3Ip6+ruBmz4JbHwP0D25Vq4E41q66zgJT+ly02QqlSltOmXQog8qaJgrPXEnffOYVi jxCKxmE0TG9H+HEbErjmlrJusfuVvqQNZkTwwoFlEtedjRka45jh5P7K3Yc+kf598Ip5 D2JA== X-Gm-Message-State: AJcUukck30BfeXVYhv+5zQrr4EzxplyRPfcJXa2Q44ce1VBDzgZMVl3n k2wDg/dfQGxBfHrzIw45pu0wdA== X-Google-Smtp-Source: ALg8bN7NAwon9EpXWKbA+wOEObc6K3NOYKFylG9qOfHTTrcc9TaCKu9rYUAf/74PfU5sBQG9Zp+F8Q== X-Received: by 2002:a17:906:e282:: with SMTP id gg2mr23596739ejb.84.1548954126060; Thu, 31 Jan 2019 09:02:06 -0800 (PST) Received: from alvin.alvh.no-ip.org ([212.76.254.98]) by smtp.gmail.com with ESMTPSA id n29sm1434196edd.40.2019.01.31.09.01.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 Jan 2019 09:01:58 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 2650F85D; Thu, 31 Jan 2019 14:01:49 -0300 (-03) Date: Thu, 31 Jan 2019 14:01:49 -0300 From: Alvaro Herrera To: Jorge Torralba Cc: pgsql-admin@postgresql.org Subject: Re: Partition detach / index question Message-ID: <201901311701.daehacbrneox@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716-1013-2c1e88 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jan-31, Jorge Torralba wrote: > Having said that, with the previous month partition detached, The index > should not be applied to that partition. Correct ? Well, if a partition is detached, it's not a partition. It's a completely separate table. > After the index is applied to all other partitions, then re-attach the old > partition. Does it automatically get the new index applied or do I have to > apply it manually? If it is automatically, will only that partition be > impacted with the locks for the index build or will all partitions be > affected? You can create indexes individually on each partition, without needing to detach anything. This is useful if you want to have indexes that exist on some partitions but not others, but otherwise it's just a maintenance headache. On the other hand, if your partitioned table has an index and you attach a table as a partition, the attach code is going to search for an index with the same definition in the partition being attached. If there is such an index, that index will be used and no new index will be created. If there is no equivalent index, a new index will be created. If you want to attach a new partition and don't want to wait for a long index build time, and your new partition already has data, you can use CREATE INDEX CONCURRENTLY on the partition before attaching. Attaching and detaching partitions acquires access exclusive lock on the parent table, on the partition being attached/detached, and on the default partition. The other partitions are not locked. Of course, if your queries go through the partitioned table instead of directly querying individual partitions, they're going to block. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services