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 1hkyLa-0003Cy-Ny for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jul 2019 22:12:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hkyLZ-0006V5-Jb for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jul 2019 22:12:25 +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 1hkyLZ-0006Uy-As for pgsql-hackers@lists.postgresql.org; Tue, 09 Jul 2019 22:12:25 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hkyLW-0003uD-BG for pgsql-hackers@lists.postgresql.org; Tue, 09 Jul 2019 22:12:24 +0000 Received: by mail-qt1-x843.google.com with SMTP id h21so248744qtn.13 for ; Tue, 09 Jul 2019 15:12:21 -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=uEleBkbvZDy+myFTT1s48QuHvIFVjqOe2QQxX8BNCIo=; b=iAlH/bDa+UwO+P4NKSgp8guUA+fTsaVhU16x0Gc9uapQKY0JJs2oo1rWJ77LQFDJa1 xHlBtCKt+xzbVZuYnG72RRFLabs5/nGcFgzmolVtYx+c5bZk6KiezdTwfalpZ8aQKMj1 0nQqohA82r28YtCGrWdwCEmPQIGcI1V81EAn3WFNcuWW+Uvi0hYBNuBA9J9ketmK6wtY e9O58BYoQPjI5sOzpQP0IEp1aBaTsmLq9/KeEuMltMyMCGrNw52tUUYXuAWzcaGMMyzY RSoQZYt2OSeMXpXtjICr1LLSdtD/djMCpT91g9VVSItJ0+fgWl+qYV3+L7qpf7U0L5fM FhMA== 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=uEleBkbvZDy+myFTT1s48QuHvIFVjqOe2QQxX8BNCIo=; b=UbOgRKdKwsSZ2b9hCksLCRVjc70MnDq+IOjPZrje+SmNQ6agO3EvMC6TlaiJv6Tocd AfAChXyqUnN1ybDCo34unfavX9dEYTUFKEN4oLU3R/tQUnBO5fi7lGG8dNq89xPNQ7MY zZBXDlZEooOXT1ji6TuXvMwlbhyI6bKoCg0f7jpUnNqA2ip6cZHOIE6fikC0ixWZwDGr UDPDxtsnXqR1ZYTRrEde4BLW4XyMXqal7Czko+mN2Ydnh2OjTMtCCCaEvPnio/TexkQH 3lWWsjJ7YrvEyTBX5t2vn2Ec4IiPjayFdfRwR+N/0bBH0FDbvGZfNzm3/wQcyCn9P/BM Aj4Q== X-Gm-Message-State: APjAAAVRUcTi1gAge4ihg97ddIDRD/7mYPskI6vwEFHhv9T34PrdFvHo vKaTkV7uTTkh376Z/cnhFESxrA== X-Google-Smtp-Source: APXvYqz/BGgeJbrJsmS7jKyine4uXP4KTQ5/Rk08gkdAYSLGZX7/6L++pj05OW0wewXaoDQYcuWmww== X-Received: by 2002:ac8:41d7:: with SMTP id o23mr18010388qtm.268.1562710340408; Tue, 09 Jul 2019 15:12:20 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id s127sm150381qkd.107.2019.07.09.15.12.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 09 Jul 2019 15:12:19 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 32DBE120219; Tue, 9 Jul 2019 18:12:17 -0400 (-04) Date: Tue, 9 Jul 2019 18:12:17 -0400 From: Alvaro Herrera To: Robert Haas Cc: Tatsuro Yamada , PostgreSQL Hackers Subject: Re: progress report for ANALYZE Message-ID: <20190709221217.GA16854@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-Jul-08, Robert Haas wrote: > On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera wrote: > > Yeah, I got the impression that that was determined to be the desirable > > behavior, so I made it do that, but I'm not really happy about it > > either. We're not too late to change the CREATE INDEX behavior, but > > let's discuss what is it that we want. > > I don't think I intended to make any such determination -- which > commit do you think established this as the canonical behavior? No commit, just discussion in the CREATE INDEX thread. > I propose that once a field is set, we should leave it set until the end. Hmm, ok. In CREATE INDEX, we use the block counters multiple times. We can leave them set until the next time we need them, I suppose. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services