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 1hA6Fi-0006bb-Ko for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Mar 2019 05:09:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hA6Fg-00052l-5a for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Mar 2019 05:09:56 +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 1hA6Ff-00052e-Ng for pgsql-hackers@lists.postgresql.org; Sat, 30 Mar 2019 05:09:55 +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 1hA6Fb-0003wl-TK for pgsql-hackers@lists.postgresql.org; Sat, 30 Mar 2019 05:09:54 +0000 Received: by mail-qk1-x744.google.com with SMTP id o129so2654697qke.8 for ; Fri, 29 Mar 2019 22:09:51 -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=DjCWdM1sKgl4XMAGjh2OCS/vLG0nj/yDHdhU0x8lSqg=; b=LFW5bWhUU5vJJvpoO29tBVpXuHfFFhckwpB80fsS/goIoKp/CePz95wSk/gEae1s+A k2gwLIxpY+/n+VBeIdqP9Sj0URV+VpEhcloKWpq4q7tFHKEb0L8XvLYSjNtChxEMIojX Fb9rwhizdAbr2HlbCWtPFIsTET1HAvso/MacNx57QrD+NP7YwGWuZbUPTCXmaMCcvfw3 1PdBuTG2ruFqPwMUX7y8eS89C6uYefosD/g9dEYD6gdDMb2KRSxzGouVaA5lLwCBg6YZ Q5ePm3kOjMhtCyf/SD9AWOFp9Q3XDKvfO6PhEKQu0LdlEwVMOo1xNkiYlSvcI7DNIOEq KRrw== 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=DjCWdM1sKgl4XMAGjh2OCS/vLG0nj/yDHdhU0x8lSqg=; b=QQVu+fmvkpUD1NAJehQAWVYO5+MDAhsq1UaQsfQkUIDijjHrH8EOp7ZbJ2CHse3qsz RqbsDdSpueMA155LX/JRZVm10pkqfjZnSZJ8ipqgbsyLKbbnYsYbGKkAR8k3TktWucwT jsWFZpTi0fzz+PcZYiJqAdjE6EvhRrpZoG8RZJOcEAw6cVaXLiSxvEESnprdL323jg3D 6jk3c8jScTQWWMTyeSpt8DRplostEyhCU+6mB/imTRsRXMiz6JqZbg3fIZD35jrpxcUb bRtBXM8/afZJTluNkxLmyt0OADyrhf3DZ6fZk/J17RdxhAJKGq4Fwy+E7i+mA8yKD8K6 bOZA== X-Gm-Message-State: APjAAAVDUQWRSe5Umagy6zF+E9b256rSrtI/rdoX/LHnTKh0of0+F6h1 UgECudl7vGhuuPnTFwfOqpXzdA== X-Google-Smtp-Source: APXvYqyQH8MqoPsQPVDHbER1PN3cQJ86vVuOV3Yo3i877Py1XNq/vQdvz22I3VPx/+WDz5xr0bq5CQ== X-Received: by 2002:a37:654e:: with SMTP id z75mr42187542qkb.314.1553922590358; Fri, 29 Mar 2019 22:09:50 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([181.226.183.151]) by smtp.gmail.com with ESMTPSA id t2sm2264325qkd.57.2019.03.29.22.09.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Mar 2019 22:09:49 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id BE31F120A6D; Sat, 30 Mar 2019 02:09:47 -0300 (-03) Date: Sat, 30 Mar 2019 02:09:47 -0300 From: Alvaro Herrera To: Robert Haas Cc: Andres Freund , Simon Riggs , Pg Hackers , David Fetter , Rahila Syed , Pavan Deolasee , Amit Langote Subject: Re: monitoring CREATE INDEX [CONCURRENTLY] Message-ID: <20190330050947.GA7954@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-29, Robert Haas wrote: > On Fri, Mar 29, 2019 at 3:28 PM Alvaro Herrera wrote: > > Maybe we can consider using dynamic shmem for that, and include a > > pointer to it in the fixed-size chunk. (It's a bit too late to be > > writing this code, mind; I'm just proposing this for a future > > improvement.) > > Sounds expensive. We don't want to spend a lot of energy pushing out > progress reports which, often enough, nobody will ever examine. I > designed the current system as I did to make it cheap. Well, I'm not proposing this for things that would change more than once or a very limited number of times during one command; certainly not once per tuple or per block like other metrics do. The examples I mentioned are once per command (eg., list of OIDs of partitions to process) or list of PIDs to wait for, which we wouldn't modify it once set for each waiting cycle (three times for CREATE INDEX CONCURRENTLY, five times for REINDEX CONCURRENTLY). > Adding DSM in there would open up lots of exciting new failure > possibilities and significantly increase the overhead. And probably > add quite a bit of code complexity, too. Yeah, that's true. Anyway, I'm not intending to tackle this for the time being. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services