Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYhaz-0005VU-8R for pgsql-hackers@arkaria.postgresql.org; Sat, 31 Oct 2020 03:30:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kYhaw-00031f-Ip for pgsql-hackers@arkaria.postgresql.org; Sat, 31 Oct 2020 03:30:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYhaw-00031Y-8L for pgsql-hackers@lists.postgresql.org; Sat, 31 Oct 2020 03:30:22 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kYhat-00008D-89 for pgsql-hackers@lists.postgresql.org; Sat, 31 Oct 2020 03:30:21 +0000 Received: by mail-io1-xd2a.google.com with SMTP id p7so9537236ioo.6 for ; Fri, 30 Oct 2020 20:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5agJKZJiEFuRYmO8ypwNGQjDE3HR32Uc5joWP+RQPgw=; b=MwvQ6HaV/614xwV94njHMAe1EZnLAcFmB0yzgYsnyEP3oVnPhWfEmugldDYlpPbuUS UGl02gRzYBxFDsJkRAMm7hk/8cSWMssT5G4E/HljVOklRUfw2KiNLQx0GAIy/7d6w0MY Slpr+SKzTZtvRcdhtgpZauPWZ7PwQT36iGt0CssuwLKyuhMzTJYJWPI3+TqDS4ZGueH/ HsmSzp20+n3Z1mWl0NHFsU8Jp+Rurls3EexadiK/i5RTuAZS9gzrR5geA6J5uw78yh5l uq3BWb2Mumf+4oPq5gN4/qVhwmYTcSE9TQpTLNlCZsHcthRtxYKAnkMfWwy5dclow4X6 jz9w== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5agJKZJiEFuRYmO8ypwNGQjDE3HR32Uc5joWP+RQPgw=; b=JdpMoSpQlODugh0VfFqN3RskjoKjf6yaFcoaUxrI8stt39MGNSJzCk71PkM3bNY9G+ SNAhyexQFsBNCNcpgZQgZGMTWpqndNAa1cMJtbTJkOE+gAvF0HgG2RrfCtBUzm++F/cd xKtxXUXLr9SmB/U0iVc+f6rOD3UbOWHQLBdoaPB8IiPabkd+AruAo9Pfjb3G59wsOoCW boAfg9qDo5r2Mvd6m4fk2jFUhe8zStJtzbyEgGF2CyK56X+o2TksKOPjUBQ5smFzHBx6 dYDYjhzeV2wZ8cLsOfvf1LRpPk4DAvDHq3avTV2i+ZPpY2iwNZ0tm+GYu+bI+FzKrFoW S2og== X-Gm-Message-State: AOAM532pFpSh3QCxPTCn3c8JDq5Ac6BIPV+GahhyhGEQi08KUw4N+pQm ObO6efZJRgSwxih2lo7gEBg9Fw== X-Google-Smtp-Source: ABdhPJxS3BoPXtFL/iScC19DGQ8RGLA7ST5hnBIwBWxlbXn1AhyNBPzRImMvIAnd1t3HjZq/Bke+oQ== X-Received: by 2002:a02:b61a:: with SMTP id h26mr4398460jam.129.1604115017049; Fri, 30 Oct 2020 20:30:17 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i201sm5947238ild.12.2020.10.30.20.30.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2020 20:30:16 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id BD9A48006D0; Fri, 30 Oct 2020 22:30:13 -0500 (CDT) Date: Fri, 30 Oct 2020 22:30:13 -0500 From: Justin Pryzby To: Michael Paquier Cc: Tomas Vondra , =?iso-8859-1?Q?Fabr=EDzio?= de Royes Mello , Tom Lane , "David G. Johnston" , pgsql-hackers@lists.postgresql.org, Nikolay Samokhvalov Subject: Re: Add important info about ANALYZE after create Functional Index Message-ID: <20201031033013.GE3080@telsasoft.com> References: <20201028185538.fzux2lhim472h46o@development> <20201028191201.wh5ldvhsiqy2vknu@development> <1443542.1603912732@sss.pgh.pa.us> <20201028193546.ayzxua26od3qnbzt@development> <20201028230211.dxbjw6mffq37mudu@development> <20201029015952.GB2671@paquier.xyz> <20201030062252.GG1693@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201030062252.GG1693@paquier.xyz> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Oct 30, 2020 at 03:22:52PM +0900, Michael Paquier wrote: > On Thu, Oct 29, 2020 at 10:59:52AM +0900, Michael Paquier wrote: > > REINDEX CONCURRENTLY is by design wanted to provide an experience > > transparent to the user similar to what a plain REINDEX would do, at > > least that's the idea behind it, so.. This qualifies as a bug to me, > > in spirit. > > And in spirit, it is possible to address this issue with the patch > attached which copies the set of stats from the old to the new index. > For a non-concurrent REINDEX, this does not happen because we keep the > same base relation, while we replace completely the relation with a > concurrent operation. We have a RemoveStatistics() in heap.c, but I > did not really see the point to invent a copy flavor for this > particular case. Perhaps others have an opinion on that? +1 The implementation of REINDEX CONCURRENTLY is "CREATE INDEX CONCURRENTLY followed by internal index swap". But the command is called "reindex", and so the user experience is that the statistics are inexplicably lost. (I'm quoting from the commit message of the patch I wrote, which is same as your patch). -- Justin