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 1i8s5a-00071j-NG for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2019 20:22: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 1i8s5Z-0004BE-GD for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2019 20:22:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i8s5Z-0004B1-1N for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2019 20:22:41 +0000 Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i8s5V-0007DX-EZ for pgsql-hackers@postgresql.org; Fri, 13 Sep 2019 20:22:40 +0000 Received: by mail-io1-xd42.google.com with SMTP id r26so65234242ioh.8 for ; Fri, 13 Sep 2019 13:22: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=JQznSs8e1/9uYYLw8jp3nhid+/Oh3qLEkdMgpZgBD+A=; b=efVc8frkAE7NEbrKZ02foNj+oKPPONNe4vW2LzwiZvJ/UboR96GkZVSBcnbWod7s5O QIKFTxPQNKJf0jcpxoh2qQF64tPfpjTis/u/d86EnBuWxjZe0wgNooISKT8jGMnxKie6 ua6ohkuUCTFdK8LIrsYNpS3QACbBMsAiF+LA8VCrrhLfOr8VXMMlE451w27WodhrN3AG Gm5ceNy33d8vAhaLBwa7F/KUrEiCr5ARuEGWRoZg/+9uJ3Kf5gtWdjkZ9b2RwTnynQfl DvTizG6ifAJrR/3AZUJRQkNlhinm9pBLbtdHoH3CGzEAWt+tF93iq6/WpZStMeX9IT7H WxDg== 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=JQznSs8e1/9uYYLw8jp3nhid+/Oh3qLEkdMgpZgBD+A=; b=dZLg03vH2gFiXFb94mU8o0dz2cvphATYck/ulrqknvLJOc9pXhWoIWgnJ7M31qSIVx DHE1pkp39TDMB74mZol1izwyqb5eOek/2JRaTAgy9t8CFssrusm3UieiFUstyzNOKP9T esp+WugcRXG1QuBISy9DiEztKYgl2tqviXqdYDvNJJfaWMaSqF+PzaMi1NV5al2nKP5v p0bvN/Jqe7I+cfsZdnwcd9pfH/fuzeCsPFfNK/I4ph3mWErYIqY2OJYAxyguI/Dkwuk6 vElZaofdBXD/hsRujDkUFG7v8yTDkDWMDSMk1pWNOaKcEn4FCPx1NheYApgg5ikIFTXC YUig== X-Gm-Message-State: APjAAAU5HV2GZ8yRBdkGp5rkVYxbYRungTLUM8cg/vU/NyknDE2mcH0z VPqeWn7q4eNI5Uqb+/K3o2FKppA7+8g= X-Google-Smtp-Source: APXvYqweVLtShlJUI9ssHwM9HfM+Cdn4H61otp2wkSiXxpx1z0ykEIiJVg7PTARGOMYbLrV+aH3eJA== X-Received: by 2002:ad4:44e2:: with SMTP id p2mr26898942qvt.126.1568390589593; Fri, 13 Sep 2019 09:03:09 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([191.125.99.73]) by smtp.gmail.com with ESMTPSA id g31sm18805276qte.78.2019.09.13.09.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Sep 2019 09:03:08 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 7922E120269; Fri, 13 Sep 2019 13:03:06 -0300 (-03) Date: Fri, 13 Sep 2019 13:03:06 -0300 From: Alvaro Herrera To: Robert Haas Cc: Michael Paquier , Masahiko Sawada , Tatsuro Yamada , Rafia Sabih , Dmitry Dolgov <9erthalion6@gmail.com>, Peter Geoghegan , PostgreSQL-development , Jeff Janes , Thomas Munro , Michael Paquier , Peter Eisentraut Subject: Re: [HACKERS] CLUSTER command progress monitor Message-ID: <20190913160306.GA1533@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: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-13, Robert Haas wrote: > On Fri, Sep 13, 2019 at 2:49 AM Michael Paquier wrote: > > On Fri, Sep 06, 2019 at 08:10:58AM -0400, Robert Haas wrote: > > > It's fine if things are updated as well -- it's just you need to make > > > sure that those places know whether or not they are supposed to be > > > doing those updates. Again, why can't we just pass down a value > > > telling them "do reindex-style progress updates" or "do cluster-style > > > progress updates" or "do no progress updates"? > > > > That's invasive. CREATE INDEX reporting goes pretty deep into the > > tree, with steps dedicated to the builds and scans of btree (nbtsort.c > > for example) and hash index AMs. > Well, if CREATE INDEX progress reporting can't be reasonably done > within the current infrastructure, then it should be reverted for v12 > and not committed again until somebody upgrades the infrastructure. Ummm ... I've been operating --in this thread-- under the assumption that it is REINDEX to blame for this problem, not CREATE INDEX, because my recollection is that I tested CREATE INDEX together with CLUSTER and it worked fine. Has anybody done any actual research that the problem is to blame on CREATE INDEX and not REINDEX? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services