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 1kXqYa-0003av-J5 for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 18:52:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXqYZ-0001oB-I7 for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 18:52:23 +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 1kXqYZ-0001o4-Bo for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 18:52:23 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kXqYS-0004Q9-LI for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 18:52:23 +0000 Received: by mail-ed1-x544.google.com with SMTP id w25so580944edx.2 for ; Wed, 28 Oct 2020 11:52:16 -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=lZk8fLLy5WqI2vebfWzHqkkjgewnz3iyxlXaPAnN0LM=; b=DmM1Mu7Ja7p5rQIBuwdImgFOvM7eeZphZn1hqq3IrvmeT3HWClb/UxBT32I1zDG0PJ W5bO6zwct7Sqk9rd4Skh9hy0pOg7kQ7RhTYQtc/srKjbb5E8pE0cAZqbLXeQqw9OCvYh K4Y5ocXl9+nygoINqg00nJ21+d624ALL6pzScWyO3yFtXqnzNj4aegta28TwvSkDjbK0 VLyqIgNA5RDcS2m07NrsyIHfQOOq+TA30lMauRUTAXnAFx1mzvpdTxfL+hUcvLbyh+e9 ZThQVmH6mS9KvosPQmmkOBox+iPcs/2R6u9Hvp/ivEWTiXmZqXAhhCe59KzqusFsRdNM 3EdQ== 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=lZk8fLLy5WqI2vebfWzHqkkjgewnz3iyxlXaPAnN0LM=; b=ctpZQOgBk5AJpf23KrNTyMs+TK8CO7GCPqbDJ45hdSHr6O0LWxOW2dW6zg53uVLRKm 6K4WLqKg3duOb3+gQuzcMH0Sy/JRNmkCzlb4rnAiT+gxse6OFIdpoU+5h0Gb68S09Zog 3FNzIdfwJuD6OlHjuHYVKLpaI/FIA0FpAYz7Tnu5SCqLR9SZxw0W6UB7yIw+hzvr2EOi bL38zINa6A9rfzActwWaC4hXjCE04WTQb5npOe0ShjA4u0lYkZ/Y1fdGUWWeTpelZeu8 YGf6ZyPCx68jK87/HVZyWInw5yfItQkNXWlyuIWkRutiBYJ7Ot9MPOZE9LmGXmbpYRlO mkNQ== X-Gm-Message-State: AOAM5312D+6LdAwDz3oBblO6uozQZ9CLXXvy0C067t5UqJU4ut+b48r3 Un0SwuTOHMQkcTvIa7JAli4/5w== X-Google-Smtp-Source: ABdhPJzjYPARzEhvuZTYYrbS9D477gktDPGBNxBHQTIKQSA50zlpqFb6sXPvJVML3wsJGD0inITEiQ== X-Received: by 2002:aa7:d710:: with SMTP id t16mr270876edq.255.1603911134825; Wed, 28 Oct 2020 11:52: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 d11sm264014eds.83.2020.10.28.11.52.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2020 11:52:14 -0700 (PDT) Date: Wed, 28 Oct 2020 19:52:11 +0100 From: Tomas Vondra To: =?utf-8?B?RmFicsOtemlv?= de Royes Mello Cc: "David G. Johnston" , Michael Paquier , PostgreSQL Hackers Subject: Re: Add important info about ANALYZE after create Functional Index Message-ID: <20201028185211.ipicbsfjsztmv6u2@development> References: 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 Tue, Oct 27, 2020 at 11:06:22AM -0300, Fabrízio de Royes Mello wrote: >On Mon, Oct 26, 2020 at 7:46 PM David G. Johnston < >david.g.johnston@gmail.com> 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. >> > >When we create a new table or index they will not have statistics until an >ANALYZE happens. This is the default behaviour and I think is not a big >problem here, but we need to add some note on docs about the need of >statistics for indexes on expressions. > I think the problem is we notice when a table has not been analyzed yet (and trigger an analyze), but we won't notice that for an index. So if the table does not change very often, it may take ages before we build stats for the index - not great. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services