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 1jhZjY-00022d-JS for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Jun 2020 14:23:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jhZjX-0007cL-Fi for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Jun 2020 14:23:39 +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 1jhZjX-0007c5-3d for pgsql-hackers@lists.postgresql.org; Sat, 06 Jun 2020 14:23:39 +0000 Received: from mail-il1-x12f.google.com ([2607:f8b0:4864:20::12f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jhZjU-0000aK-9C for pgsql-hackers@lists.postgresql.org; Sat, 06 Jun 2020 14:23:37 +0000 Received: by mail-il1-x12f.google.com with SMTP id g3so12420432ilq.10 for ; Sat, 06 Jun 2020 07:23:35 -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:content-transfer-encoding:in-reply-to :user-agent; bh=ekxQvbIDwtaMjVoh5in/ntMVuIH3iXY+UheKUEvImtQ=; b=N8RXvYqtgyVvKQ9mI4Mzfkw10l9lEFyl5hqcefp85mIUX4+UuhQXPQee/UWed56gU5 gRacpCEhFmD2A9bFhnakWxDd87AT5P4jmsfhr6Kw6Zb1hl0/gfUdnin4RIuNSvImT+0t fRIu6UbcC3b7EBLshn+KBcRWhjO39SPhvZ7E/a8f0rylkjmfKiE5aFOEtbQ1pppVarrV uWxDo4CYGfzVKDBWHAY4k6I42WODvH4fWBTXG7TuDV2iRT6vVLz9h69rEU4yEL24dtuD YCizPC5g7N5Q9RlB4TazpRk6M5P9o4ipIkeJ1eoPECbT1cLoIrGsc+pgBW84hcTVurHy VN9g== 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:content-transfer-encoding :in-reply-to:user-agent; bh=ekxQvbIDwtaMjVoh5in/ntMVuIH3iXY+UheKUEvImtQ=; b=iVpry/y/xti+0vSvoiJMU+xooofmlOsj/vajkA38m82KFLAlhYUxP6YNxpm8FByg/1 X3WJJf7du0nY7jvIjh7Fv7e4rru46fenSBEJgVH6XOQik4YD9CziARX0DKUjZkFPjSo6 5E75yClqKnKuIOCOiZK92nolS/eOAHSWE0dNAkdnFdmyIYy6hyYaCHtcFndvFvyYP7Uj 8c9EL+DNfxFlioWhL5zZx8zoCLlBtHt4rFDGwyxEONvFpvl0CmpQe9BskmFWZCEQua6N E8PigNbY0Tlt0vPa5U4Rjo879UngNe424kfZ3k+T+22xKzhi5mVPpqN4ULuBd/tL7wCE CPfQ== X-Gm-Message-State: AOAM532WYzM3iUXgGPDywaXUM5juO7c89EKITHtMab974OY2nhaR0iiE IsgUZ5Nktey0Vm9aaZxESkMiPg== X-Google-Smtp-Source: ABdhPJzKqcMJKvIx8Czv6nwpXmFBb/Fjo+4/695ITAkSP7rWDgIFtFzCOSISTOn2k0QUJjoqAMI+/g== X-Received: by 2002:a92:995a:: with SMTP id p87mr6180104ili.21.1591453414787; Sat, 06 Jun 2020 07:23:34 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id r1sm4692960iln.77.2020.06.06.07.23.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2020 07:23:34 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 061D68002B8; Sat, 6 Jun 2020 09:23:32 -0500 (CDT) Date: Sat, 6 Jun 2020 09:23:32 -0500 From: Justin Pryzby To: =?utf-8?B?5p2O5p2wKOaFjui/vSk=?= Cc: pgsql-hackers , =?utf-8?B?5pu+5paH5peMKOS5ieS7jik=?= Subject: Re: how to create index concurrently on paritioned table Message-ID: <20200606142332.GH22473@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote: > Partitioning is necessary for very large tables. > However, I found that postgresql does not support create index concurrently on partitioned tables. > The document show that we need to create an index on each partition individually and then finally create the partitioned index non-concurrently. > This is undoubtedly a complex operation for DBA, especially when there are many partitions. > Therefore, I wonder why pg does not support concurrent index creation on partitioned tables? > What are the difficulties of this function? > If I want to implement it, what should I pay attention? Maybe I'm wrong, but I don't think there's any known difficulty - just that nobody did it yet. You should pay attention to what happens on error, but hopefully you wouldn't need to add much code and can rely on existing code to paths to handle that right. I think you'd look at the commits and code implementing indexes on partitioned tables and CREATE INDEX CONCURRENTLY. And maybe any following commits with fixes. You'd first loop around all children (recursively if there are partitions which are themselves partitioned) and create indexes concurrently. -- Justin