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 1hK5yh-0005Us-5Q for pgsql-docs@arkaria.postgresql.org; Fri, 26 Apr 2019 18:53:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hK5yf-00088t-1s for pgsql-docs@arkaria.postgresql.org; Fri, 26 Apr 2019 18:53:41 +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 1hK5ye-00088m-NC for pgsql-docs@lists.postgresql.org; Fri, 26 Apr 2019 18:53:40 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK5yb-0004Rh-NY for pgsql-docs@lists.postgresql.org; Fri, 26 Apr 2019 18:53:39 +0000 Received: by mail-qt1-x841.google.com with SMTP id g7so5332108qtc.0 for ; Fri, 26 Apr 2019 11:53:37 -0700 (PDT) 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=f6CsxHhvvnprK0xpj40T0Y3Unl1qRhu8u7ktZ1tP60I=; b=XNEYOvqM7ZeAfUr9Iu6qtlrY3E00gPiuWgVPEdDhyARnPDByqV6fHUeDmn9umlIUVh PysozJZycNbV+dQsZO0E6K+t2EjeOBMrouUxSPoVvcU8gjh0/HIqdFf2ybDDMIlNnLjJ LOnCRm5tQzfJmQoOr8pcI5Z/N5if65FE/ntr3Ni0aY9m3NdbDgob4AWDBq/6GxoP6jtK Ms6Huve/asNraagq9z6QSJg+/XeBp/YgRjrQa0CePro35EcSZKQ/fnMh82z0TKRItr1s cbfcgDcezL2VGzCZqqcx/fickAR1215wRLIoSwfbVH4WkMl4PedSGESt1Jl2hF9bgDJ2 VErg== 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=f6CsxHhvvnprK0xpj40T0Y3Unl1qRhu8u7ktZ1tP60I=; b=fqoi7iOr2rwzvgER69Tw99PbLgh+w6X4lfz5Yzh0LFx4Oh5bJjiSYHTsGUA/RQ/pyD y2PEHWYYdIhJEA1b8YbmxOfmYNKYDtnkoWFoADgR0Vwm1TVO4MfzSP2aYYVntld3sGRb UlLW1QR0eXft5fnw2+Bt4DstpAgtyrRkkQvwJVxBL8tQv1HMuNEsno/uVnHkD8b/9aKb aeQ4eEeVs2ePLI1aa70Jf3OjiQLWfw50W053KhZQMhfhxzi5p43H2JApE4CSW9QX2jOL 5Uunz7PtCYVxB9OO8IeHePK9F6cMs+5NkFQ5GdIqbN0aFXf+j2OoCNTmKllGdVVFLR0C j6Vw== X-Gm-Message-State: APjAAAWgndUe+agjMUwKDgfXGCjuRnNNl7gaOO1CAv4Nvzwu9VdcMy2n 7LvPKolXhp6nd7Vhsr0khBGPl3sVn1icT6nBFQsj8YXA7XBQ9IzGcqdNp40XbLO3KvfufYd7+d3 XJP5l0tbwyUzYi1yWTwteIuY9b5JSJ8mLoppnKtBYxO+PnqXFIf/CGNgHaXLm/5rCul9aGOw25q w5I34bZA8DsQ== X-Google-Smtp-Source: APXvYqzaHWoUE0W6snEPePqIDnyWYhRpB3qDA0SJr7rgBtyLhgz0u4DOS8tSMxwfmJjdqMPTeldH8Q== X-Received: by 2002:ac8:2195:: with SMTP id 21mr37858176qty.182.1556304816687; Fri, 26 Apr 2019 11:53:36 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id d34sm18279426qta.18.2019.04.26.11.53.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 11:53:35 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 26819120779; Fri, 26 Apr 2019 14:53:33 -0400 (-04) Date: Fri, 26 Apr 2019 14:53:33 -0400 From: Alvaro Herrera To: Tom Lane Cc: pgsql-docs@lists.postgresql.org Subject: Re: Documentation for partitioned indexes? Message-ID: <20190426185333.GA12464@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8756.1556302759@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Apr-26, Tom Lane wrote: > We appear to have a fair amount of support now for operations like > constructing a partitioned index piecemeal, e.g. adding indexes > to the partitions one at a time and then attaching them to a > parent partitioned index, with the parent ultimately transitioning > from "not valid" to "valid" once all the pieces are attached. > > However, I cannot find any coherent documentation explaining how > to do this (or why you'd want to). Am I just looking in the wrong > places? Hmm. Under Notes for CREATE INDEX there is a paragraph on this: When CREATE INDEX is invoked on a partitioned table, the default behavior is to recurse to all partitions to ensure they all have matching indexes. Each partition is first checked to determine whether an equivalent index already exists, and if so, that index will become attached as a partition index to the index being created, which will become its parent index. If no matching index exists, a new index will be created and automatically attached; the name of the new index in each partition will be determined as if no index name had been specified in the command. If the ONLY option is specified, no recursion is done, and the index is marked invalid. (ALTER INDEX ... ATTACH PARTITION marks the index valid, once all partitions acquire matching indexes.) Note, however, that any partition that is created in the future using CREATE TABLE ... PARTITION OF will automatically have a matching index, regardless of whether ONLY is specified. I suppose I better add something in Chapter 5 (DDL), possibly inside the 5.10 section (Table Partitioning) -- a new 5.10.6 "Indexes for Partitioned Tables" perhaps? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services