From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: David Steele <david@pgmasters.net>, Stephen Frost <sfrost@snowman.net>,
        Michael Paquier <michael.paquier@gmail.com>,
        Haribabu Kommi <kommi.haribabu@gmail.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means
In-reply-to: <3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com>
References: <16db4468-edfa-830a-f921-39a50498e77e@2ndquadrant.com>
 <19990.1500936945@sss.pgh.pa.us>
 <3d250597-384e-c5f4-7533-b513e366888f@2ndquadrant.com>
 <CAJrrPGeQcsBXhuJA1vQ25PS0wAqfo0v_mXtwmt4VcOmxKSvfCA@mail.gmail.com>
 <94f58897-861b-accf-a9f1-af4be816c0d3@2ndquadrant.com>
 <CAJrrPGfTQ3w=5BdprWgQghuM7ujtBy2Sthr6zRwY0QeRBQd2RQ@mail.gmail.com>
 <13097.1509650125@sss.pgh.pa.us>
 <3dca6a76-fa4b-66ab-c0db-496335d650b1@2ndquadrant.com>
 <CAB7nPqS4VSUiaFnGmR2k95-RtEi++SEwZk32pMu_31VLyMpK0Q@mail.gmail.com>
 <20180105042528.GK2416@tamriel.snowman.net>
 <1e831867-c46c-8f21-79d4-5de70cac5822@2ndquadrant.com>
 <13711.1515440364@sss.pgh.pa.us>
 <01387f5d-a95b-d159-becb-cf9ff9ba4e41@2ndquadrant.com>
 <db11d513-4af4-0d1b-514b-16617385f068@pgmasters.net>
 <8b29edcb-cbc0-5414-996f-520f75b94d3b@2ndquadrant.com>
 <3b3d8eac-c709-0d25-088e-b98339a1b28a@2ndquadrant.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Tue, 20 Mar 2018 21:14:04 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14502.1521739732.1@sss.pgh.pa.us>
Date: Thu, 22 Mar 2018 13:28:52 -0400
Message-ID: <14503.1521739732@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> 0001 fixes this by tracking the number of actually indexed rows in the
> build states, just like in the other index AMs.
> A VACUUM or ANALYZE will fix the estimate, of course, but for tables
> that are not changing very much it may take quite a while. So I think
> this is something we definitely need to back-patch.

Agreed, and done.  I noticed a second bug in contrib/bloom, too: it'd
forget to write out the last index page if that contained only one
tuple, because the new-page code path in bloomBuildCallback failed to
increment the "count" field after clearing it.

> The 0002 part is the main part, unifying the definition of reltuples on
> three main places:

On to this part ...

			regards, tom lane