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 1h1KyN-00042X-6h for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 01:03:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h1KyK-0008Hn-5S for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 01:03:48 +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 1h1KyJ-0008FE-Pv for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 01:03:47 +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 1h1KyH-00042B-2N for pgsql-hackers@postgresql.org; Wed, 06 Mar 2019 01:03:47 +0000 Received: by mail-qk1-x744.google.com with SMTP id r21so5871184qkl.11 for ; Tue, 05 Mar 2019 17:03:44 -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=P+hqA3mrHLOOj0fMuYbj5k9d9twOKpUVKwM68cgyb48=; b=RDSIbdFoYfiyn9weKP/JLU9O+/fnhCPrqbtUlJ9X1RtyxJ5JgmtZ73CXkVD3PdFwzs qBLvgLcNVyfWE6jCLldN8rhtXtLdBmJPrsJ94cYy+Xi4mK2pxItyuJ/MiIMfT94GSCDb OlorKegjt7anw/oVVEPDcRFrk6i7UZX5GiriJe30ntTLZy5cLdD28kl0Zk2jwa76KyEl rctwQ/DnAOBiaJrHYV0rYNsnfojry7ThXAhR7fu+Y1FFTsIPTZzSME82OkRTL+Sp/+F3 6mh6Cl4VAVWoRUvjmi39vbccEKN4Acw3ty/kIxDurptA1h/0Sl3wpuXI0u6KlnZifa3q lr3Q== 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=P+hqA3mrHLOOj0fMuYbj5k9d9twOKpUVKwM68cgyb48=; b=aT3oZXgr0/b817UwkKmoyb/zADRzePmnvf9bKWNm+TPo40S1Ni0ftDPR66NCyiK48t A/4bWL8V86fzvbKYfkBEO7rD1JFHWhFmHdKfaBQdbH6S/9RvuB7vX1j0yAs7MRClBhmF DKJ1nCgknTXL0THIkwNkLuldUbLa3LofAyEodFjpa7lTs/aNJi2JjEOtBcVJ7Y7ruRHP V2SaDrQbvfes43tMpwt1TGUdJ6QmAWCsG70T7++7122Phhmjj/q/r8ghxrPtE+VVVa8N 9aFB9mBlDFQ2sM61E+LANWuNIuQf0nQOfiY7VABLpuFC4vLlNPhMeEIaTtXyFanuUdgk CiYw== X-Gm-Message-State: APjAAAWOFHYPCH+N1G9hZAwZItBjM8NYqVwQQFLjtHa5c1fS3QRYvUEE FFZHRwUDf9KX4HLy+/+jdm5NGw== X-Google-Smtp-Source: APXvYqwEMj253dgq5C3TDiVPPdv71Z0xqORD1PebooUoZplGUP59k/g/h2C2m4sQlXlecox01wN9AA== X-Received: by 2002:a05:620a:1295:: with SMTP id w21mr3960127qki.7.1551834223282; Tue, 05 Mar 2019 17:03:43 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id m26sm132827qtf.4.2019.03.05.17.03.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Mar 2019 17:03:42 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 23410121942; Tue, 5 Mar 2019 22:03:38 -0300 (-03) Date: Tue, 5 Mar 2019 22:03:38 -0300 From: Alvaro Herrera To: Robert Haas Cc: Tatsuro Yamada , Dmitry Dolgov <9erthalion6@gmail.com>, Peter Geoghegan , PostgreSQL-development , Jeff Janes , Thomas Munro , Michael Paquier Subject: Re: [HACKERS] CLUSTER command progress monitor Message-ID: <20190306010338.GA20820@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-Mar-04, Robert Haas wrote: > On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada > wrote: > > === Discussion points === > > > > - Progress counter for "3. sorting tuples" phase > > - Should we add pgstat_progress_update_param() in tuplesort.c like a > > "trace_sort"? > > Thanks to Peter Geoghegan for the useful advice! > > How would we avoid an abstraction violation? The theory embodied in my patch at https://postgr.es/m/20190304204607.GA15946@alvherre.pgsql is that we don't; tuplesort.c functions (index.c's IndexBuildHeapScan in my case) would get a boolean parameter to indicate whether to update some params or not -- the param number(s) to update are supposed to be generic in the sense that it's not part of any individual command's implementation (PROGRESS_SCAN_BLOCKS_DONE for what you call "blks scanned", PROGRESS_SCAN_BLOCKS_TOTAL for "blks total"), but rather defined by the "progress update provider" (index.c or tuplesort.c). One, err, small issue with that idea is that we need the param numbers not to conflict for any "progress update providers" that are to be used simultaneously by any command. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services