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 1kXuST-0007nL-CD for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 23:02:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXuSR-0005Fv-Ci for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 23:02:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXuSR-0005EP-2j for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 23:02:19 +0000 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kXuSO-0000DT-3E for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 23:02:17 +0000 Received: by mail-ej1-x643.google.com with SMTP id 7so1296804ejm.0 for ; Wed, 28 Oct 2020 16:02:15 -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:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=HOjidu2uiGPWUY5ev0YxZLXZQE4Q2XI929P+EJh/3xU=; b=vE09rKQwtSDcBG7wjORaNcJUwEImaAbjrwVdHnyNadYX0GnuVN1laxsSUbkVltLsfK /X4j8NpbpPdwbrP+iJRx1G/cFfYBs9LINwSq5XOJ4cgdWCgE3+82PEzd3Vi9w2Yav7fO pWego0xvH6nTVWJcmUcrINKkrV/YJI+Ip2ojBt2kBJsgBhlnX8rRFygOuKWcjq31zyrq AgB4YW//gSqBgjahlo8bIKmssYnTJuIVsBBEFuK0XbO0theKjdviCOMm/DH9Pk2PgTOA 5lZGwUw54vp/3CrwdCK27LZD+OnGIAZijCHl5Zp0DB/kAUoEKz40gr3QpHUkEgMuHA9M Q5lA== 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:content-transfer-encoding :in-reply-to; bh=HOjidu2uiGPWUY5ev0YxZLXZQE4Q2XI929P+EJh/3xU=; b=shc/ORL6OeQak5/+RcxKOev3WPDc2+qtbiNTcnVp2hZrBaW+Dk4qzCeUIAlZzx4Xzo 3bzTDQ4jo83aCIJt36tqv8OssTo0q+tT6n+HD/yjUwyfangOhwsPSuCLD3gGrC6/lH+j h4eljWV95/pAl/O7V3anadXL4jz+mxlCq18hx5MFJG0wBZFyO53WKyzBs6lnFR81vJ3E v8lpEyIFSH2s2RzCjhQ8RsnDM0qGZZJKkpFN7Wb5dHOi66w+bskd9va+X74t6+9FnWZq zEvAL8UTRCNRb/cV4H6RgqzqEN94yK3GrKsYWTvPbtc2NRzoFu3h8jrToO2EYvBlXB5K 5Lqw== X-Gm-Message-State: AOAM530I6EnUnVeWx8+t4HexXaiKif3dKD3XU6zDVaWPowRwfHTDokbD C8p4LSgAIpgR6ZNAvW2BwgGJtQ== X-Google-Smtp-Source: ABdhPJwXfF+izdNovLF/C1JNbXooD1Pi1IzmQCY9uNN5jsraEBo9tnbPl6tZuG2EdK7DAuEq/CsdMQ== X-Received: by 2002:a17:906:1a57:: with SMTP id j23mr1372507ejf.291.1603926134265; Wed, 28 Oct 2020 16:02:14 -0700 (PDT) Received: from localhost (ip-86-49-245-76.net.upcbroadband.cz. [86.49.245.76]) by smtp.gmail.com with ESMTPSA id ks17sm466681ejb.41.2020.10.28.16.02.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2020 16:02:13 -0700 (PDT) Date: Thu, 29 Oct 2020 00:02:11 +0100 From: Tomas Vondra To: =?utf-8?B?RmFicsOtemlv?= de Royes Mello Cc: Tom Lane , "David G. Johnston" , PostgreSQL Hackers , Nikolay Samokhvalov , Michael Paquier Subject: Re: Add important info about ANALYZE after create Functional Index Message-ID: <20201028230211.dxbjw6mffq37mudu@development> References: <20201028185538.fzux2lhim472h46o@development> <20201028191201.wh5ldvhsiqy2vknu@development> <1443542.1603912732@sss.pgh.pa.us> <20201028193546.ayzxua26od3qnbzt@development> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Oct 28, 2020 at 05:43:08PM -0300, Fabrízio de Royes Mello wrote: >On Wed, Oct 28, 2020 at 4:35 PM Tomas Vondra >wrote: >> >> I don't think anyone proposed to do this through autovacuum. There was a >> reference to auto-analyze but I think that was meant as 'run analyze >> automatically.' Which would work in transactions just fine, I think. >> > >Maybe I was not very clear at the beginning so will try to clarify my >thoughts: > >1) We should add notes on our docs about the need to issue ANALYZE after >creating indexes using expressions and create extended statistics. Nikolay >sent a patch upthread and we can work on it and back patch. > +1 >2) REINDEX CONCURRENTLY does not keep statistics (pg_statistc) like a >regular REINDEX for indexes using expressions and to me it's a bug. Michael >pointed out upthread that maybe we should rework a bit >index_concurrently_swap() to copy statistics from old index to new one. > Yeah. Not sure it counts as a bug, but I see what you mean - it's definitely an unexpected/undesirable difference in behavior between plain REINDEX and concurrent one. > >> But I agree it'd likely be a more complicated patch than it might seem >> at first glance. >> > >If we think about a way to kick AutoAnalyze for sure it will be a more >complicated task but IMHO for now we can do it simply just by copying >statistics like I mentioned above. > I very much doubt just we can rely on autoanalyze here. For one, it'll have issues with transactions, as Tom already pointed out elsewhere in this thread. So if you do a reindex after a bulk load in a transaction, followed by some report queries, autoanalyze is not going to help. But it has another issue - there may not be any free autovacuum workers, so it'd have to wait for unknown amount of time. In fact, it'd have to wait for the autovacuum worker to actually do the analyze, otherwise we could still have unpredictable behavior for queries immediately after the REINDEX, even outside transactions. That's not good, so this would have to do an actual analyze I think. But as Tom pointed out, the automatic analyze may be against wishes of some users, and there are other similar cases that don't trigger analyze (CREATE STATISTICS). So not sure about this. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services