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 1h8c0E-0003Lz-HH for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2019 02:39:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h8c0D-0002yh-8r for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2019 02:39:49 +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 1h8c0D-0002ya-1R for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2019 02:39:49 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h8c0A-0001Fk-7x for pgsql-hackers@lists.postgresql.org; Tue, 26 Mar 2019 02:39:48 +0000 Received: by mail-qk1-x744.google.com with SMTP id z76so6693340qkb.12 for ; Mon, 25 Mar 2019 19:39:46 -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=nk/gS0H7+rQBsnZOLLGVUxNEV9L4SHPEDzydjWPb0UY=; b=LeYJIV5a36iWnsE4e2toJhmcFMSijAmRRZ54BUyZ397xGUsIFm6ZVBUbOKdSGBRiV/ zm0Q5nLsNJT4IvRZ3k00A2JZ1U7izfRmZMAvhzw9c23PUHi5ryveCVxebmF/keqyVCXi TR+AABjQq6qq+EYyRVoxSnJbJukxHij5lqYaIVU5SGOedBj42jU78B8FJ2xcOHxc73xG lfvIG+NsFeBZJvCrQiYw+xsArS8Yj2elNDiwigct3T6sS0RBg7uBvp/omK2eLoSBIfre vV6A+RNoC7fB1QwFVDtXti5fAc2RKGQPvti2AOFWwDVKkSi8y50L1VSo9Tl/ruCEqyIP MK+g== 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=nk/gS0H7+rQBsnZOLLGVUxNEV9L4SHPEDzydjWPb0UY=; b=TiIL7FYGLVlmnr7bxLWcgcT1UtQhxCG+YHgwrKDNzbsFTtvSw65yw88IGsblPLyCX0 NqrAKDi9UKXCIwEOQTwtrG5+GPfQQZCoRS0SFWLWUWt0sqIA1v/uU5JA+PauYcyN4WCL xlodtEVcf+HdISmUgErbZTiL238MSnPl8jJ5eusJr74DOxY5XX5JeokRpAlWPpXxU0NK M6WMzH9jsOCOxnvogh97X23sajfVU9mZJLEJ0+IG5lBUXlG2K+c5is08wUA+4XkJ0jHH WPMtDJby9gM0tultRY59cCJuGYoYDn80BiWThYmn7hjKFR4w/d6QTfprLRIiJxw4GJVH KKKQ== X-Gm-Message-State: APjAAAWKGEOcbBu360kt9famAURjO1zMnM0F8o3aeFisUPt97/zyUDJC 9DkYx1HARI6fP/y13KS28fJIHg== X-Google-Smtp-Source: APXvYqz9rrVqBqK1ocZlkDRn8u9Lmi9VsNjFTwM+mzSSzlEQvYUlMEw9lJzjPeGIzLhcop2Arh/FDA== X-Received: by 2002:a37:7e83:: with SMTP id z125mr22100068qkc.351.1553567984546; Mon, 25 Mar 2019 19:39:44 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id j17sm12229941qtj.61.2019.03.25.19.39.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 19:39:43 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 4CE2D1205F1; Mon, 25 Mar 2019 23:39:42 -0300 (-03) Date: Mon, 25 Mar 2019 23:39:42 -0300 From: Alvaro Herrera To: Andres Freund Cc: Pg Hackers , David Fetter , Robert Haas , Rahila Syed , Simon Riggs , Pavan Deolasee , Amit Langote Subject: Re: monitoring CREATE INDEX [CONCURRENTLY] Message-ID: <20190326023942.GA5997@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190326021809.se3efuathoetxf2u@alap3.anarazel.de> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi On 2019-Mar-25, Andres Freund wrote: > I've not followed this thread at all, so I might just be out of my depth > here. From my POV, a later patch in the yet-to-be-applied patchqueue > moves the main part of cluster below the table AM (as there's enough low > level details, e.g. dealing with HOT). Therefore I don't have a problem > having heap's implementation interrogate the scan in a heap specific > manner. > > Is that the angle you were wondering about? If not, any chance to point > out more precisely what to look at? > > Obviously out of pure laziness, I'd prefer this to go in after my move > of index creation scans & cluster below tableam.h. But admittedly, > managing my exhaustion isn't the the sole goal of the project.... Well, this is create index rather than cluster, but yes this conflicts pretty heavily with patch 0008 in your v21 at 20190324031630.nt7numguo5ojq6uv@alap3.anarazel.de. I wonder if I should rather push and help merge your 0008, or wait until you push and deal with it afterwards. I'd rather do the former, I think. Anyway I was thinking about the conceptual angle -- the progress monitoring stuff is doing block-based reporting. I think even if we get a non-block-based heap, we can still report the number of physical blocks already processed by the scan, which is what the index build monitoring is interested in showing the user. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services