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 1kXqtS-0004HV-SF for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 19:13:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXqtR-0008Pj-Qk for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 19:13:57 +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 1kXqtR-0008Pb-Js for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 19:13:57 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kXqtN-0006sh-Ad for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 19:13:56 +0000 Received: by mail-ed1-x541.google.com with SMTP id l24so595005edj.8 for ; Wed, 28 Oct 2020 12:13:53 -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:in-reply-to; bh=Lh9/gQvD0OMy4eMr25hXLNgY2ya7y/KMj9eF5/7OnXc=; b=geWjnX404PSl7SnhpqShwR9OSiD+LUYeHjALPG37x4z/BrHQqBvwo4/rwbfzurQ27R yk7tRW/1duj37FJSMC8DqXYJ9eRN8eWFO2LZuA/2y0ZdN/EJ/rNEXqAjn4VosXPG8GKq oIJcbspZwnF60Mjb3uQjagzymUsgWQ12bPxf0O+2jQdgbCCUTJD7LiVmJXdCLeGbtddJ wULcLRsva61idVT5CN0zzkrn/orDiqXMUknYRsSfU3hVVfMhkpJxyCD4ZqSC2zDj+9Fr iM2stnUMTupvGtmTL/VXr46tSqkBSQfYQGnNJ7g729Dsts1Mh+NdWaYgxedxoCPJZJi9 X35A== 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; bh=Lh9/gQvD0OMy4eMr25hXLNgY2ya7y/KMj9eF5/7OnXc=; b=cAktcbkPD3MW3QYAj4VB1Y+vFN0lVc0XeKHsrEXcySc9tAQ6NtITQQgUJbkrWFL8Ux r2qJQ7gqTQfoUt3+wukdOOlqdU+3C3CVSOZ4O+IjY7Dzi3Qe9qe/FyYA8j0vantu2sFy 60/WhVJlW6j3MU8O2T76tv9pIPQTGL9kzeXEcJL4C8naiZTd2LGkD1h4TcH5DgMlelw/ YVwQrONPAEBz/znk4nKcAsGgUHSDNPXw9ipXNa1L7skMZia9+WfdlohuCd/7pMqz69fD WgYR3QBwOAmiUvES96P0xBT4ADt45U7QDKmS9NdIeTGTntNAqLpAuTKvgEHcOvXE1Yab ODdg== X-Gm-Message-State: AOAM530SLK1wnF9p9F3r7gwSRfKcfU4utCe6zMMbCO33RVb8BuOJ9bjv JgBdeKktMMHrRWdGJfbSzfjI/A== X-Google-Smtp-Source: ABdhPJwBesR6QS3x95Ltc4bunB1db+Hrj8jt4tHFMOnB4a74tBVEKPV52Cy8g0HeuWXqYU8ghawbSQ== X-Received: by 2002:a50:b224:: with SMTP id o33mr386796edd.21.1603912431849; Wed, 28 Oct 2020 12:13:51 -0700 (PDT) Received: from localhost (ip-86-49-245-76.net.upcbroadband.cz. [86.49.245.76]) by smtp.gmail.com with ESMTPSA id p3sm311017edy.38.2020.10.28.12.13.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2020 12:13:51 -0700 (PDT) Date: Wed, 28 Oct 2020 20:13:48 +0100 From: Tomas Vondra To: Tom Lane Cc: "David G. Johnston" , =?utf-8?B?RmFicsOtemlv?= Mello , PostgreSQL Hackers Subject: Re: Add important info about ANALYZE after create Functional Index Message-ID: <20201028191348.u4jwtawz4c533xge@development> References: <20201028185538.fzux2lhim472h46o@development> <1442677.1603911939@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1442677.1603911939@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Oct 28, 2020 at 03:05:39PM -0400, Tom Lane wrote: >Tomas Vondra writes: >> On Mon, Oct 26, 2020 at 03:46:10PM -0700, David G. Johnston wrote: >>> It would seem preferable to call the lack of auto-analyzing after these >>> operations a bug and back-patch a fix that injects an analyze side-effect >>> just before their completion. It doesn't have to be smart either, >>> analyzing things even if the created (or newly validated) index doesn't >>> have statistics of its own isn't a problem in my book. > >> I agree the lack of stats may be quite annoying and cause issues, but my >> guess is the chances of backpatching such change are about 0.000001%. We >> have a usable 'workaround' for this - manual analyze. > >This doesn't seem clearly different from any other situation where >auto-analyze doesn't react fast enough to suit you. I would not >call it a bug, at least not without a wholesale redefinition of >how auto-analyze is supposed to work. As a close analogy, we >don't make any effort to force an immediate auto-analyze after >CREATE STATISTICS. > True. >I don't see anything in the CREATE STATISTICS man page pointing >that out, either. But there's probably room for "Notes" entries >about it in both places. > I agree. I'll add it to my TODO list for the next CF. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services