Jean-David Beyer <jeandavid8@verizon.net> writes: > I am doing lots of INSERTs on a table that starts out empty (I did a > TRUNCATE on it). I am not, AFAIK, doing DELETEs or UPDATEs. Autovacuum is > on. I moved logging up to debug2 level to see what was going on, and I get > things like this: > "vl_as": scanned 3000 of 5296 pages, containing 232944 live rows and 1033 > dead rows; 3000 rows in sample, 411224 estimated total rows > A little later, it says: > "vl_as": scanned 3000 of 6916 pages, containing 233507 live rows and 493 > dead rows; 3000 rows in sample, 538311 estimated total rows Well, *something* is doing deletes or updates in that table. Better look a bit harder at your application ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Russell Smith <mr-russ@pws.com.au> writes: > It is possible that analyze is not getting the number of dead rows right? Hah, I think you are on to something. ANALYZE is telling the truth about how many "dead" rows it saw, but its notion of "dead" is "not good according to SnapshotNow". Thus, rows inserted by a not-yet-committed transaction would be counted as dead. So if these are background auto-analyzes being done in parallel with inserting transactions that run for awhile, seeing a few not-yet-committed rows would be unsurprising. I wonder if that is worth fixing? I'm not especially concerned about the cosmetic aspect of it, but if we mistakenly launch an autovacuum on the strength of an inflated estimate of dead rows, that could be costly. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend