Tom Lane 7c91a0364f Sync up our various ways of estimating pg_class.reltuples. ... VACUUM thought that reltuples represents the total number of tuples in the relation, while ANALYZE counted only live tuples. This can cause "flapping" in the value when background vacuums and analyzes happen separately. The planner's use of reltuples essentially assumes that it's the count of live (visible) tuples, so let's standardize on having it mean live tuples. Another issue is that the definition of "live tuple" isn't totally clear; what should be done with INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples? ANALYZE's choices in this regard are made on the assumption that if the originating transaction commits at all, it will happen after ANALYZE finishes, so we should ignore the effects of the in-progress transaction --- unless it is our own transaction, and then we should count it. Let's propagate this definition into VACUUM, too. Likewise propagate this definition into CREATE INDEX, and into contrib/pgstattuple's pgstattuple_approx() function. Tomas Vondra, reviewed by Haribabu Kommi, some corrections by me Discussion: https://postgr.es/m/16db4468-edfa-830a-f921-39a50498e77e@2ndquadrant.com		2018-03-22 15:47:41 -04:00
..
expected
sql
.gitignore
Makefile
pgstatapprox.c	Sync up our various ways of estimating pg_class.reltuples.	2018-03-22 15:47:41 -04:00
pgstatindex.c	Remove unnecessary parentheses in return statements	2017-09-05 14:52:55 -04:00
pgstattuple--1.0--1.1.sql
pgstattuple--1.1--1.2.sql
pgstattuple--1.2--1.3.sql
pgstattuple--1.3--1.4.sql
pgstattuple--1.4--1.5.sql
pgstattuple--1.4.sql
pgstattuple--unpackaged--1.0.sql
pgstattuple.c	Fix more format truncation issues	2018-03-15 11:41:42 -04:00
pgstattuple.control