| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means |
| Date: | 2018-03-22 20:15:27 |
| Message-ID: | b6ef4913-f7ec-93ad-e774-49c7be04d963@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03/22/2018 08:51 PM, Tom Lane wrote:
> I wrote:
>> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>>> The 0002 part is the main part, unifying the definition of reltuples on
>>> three main places:
>
>> On to this part ...
>
> I've pushed 0002 with several corrections: it did not seem to me that
> you'd correctly propagated what ANALYZE is doing into CREATE INDEX or
> pgstattuple. Also, since one of the things VACUUM does with num_tuples
> is to report it as "the total number of non-removable tuples", I thought
> we'd better leave that calculation alone. I made the added code count
> live tuples in a new variable live_tuples, instead.
>
OK, makes sense. Thanks.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-03-22 20:19:11 | Re: parallel append vs. simple UNION ALL |
| Previous Message | Tom Lane | 2018-03-22 19:51:25 | Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means |