On Wednesday, June 26, 2013 7:40 AM Kyotaro HORIGUCHI wrote: > I've recovered from messing up. > > <snip> > > Please let me have a bit of time to diagnose this. > > I was completely messed up and walking on the wrong way. I looked into > the vacuum for UPDATEs, not DELETE's so it's quite resonable to have > such results. > > The renewed test script attached shows the verbose output of vacuum > after the deletes. I had following output from it. > > # I belive this runs for you.. > > | INFO: "t": found 989999 removable, 110 nonremovable row > | versions in 6308 out of 10829 pages > > On such a case of partially-scanned, lazy_scan_heap() tries to estimate > resulting num_tuples in vac_estimate_reltuples() assuming the > uniformity of tuple density, which failes for such a a strong imbalance > made by bulk updates. > > Do you find any differences between what you will have and the > following I had?
I could see the same output with your latest script, also I could reproduce the test if I run the test with individual sql statements. One of the main point for reproducing individual test was to keep autovacuum = off. Now I can look into it further, I have still not gone through in detail about your new approach to calculate the reltuples, but I am wondering whether there can be anyway with which estimates can be improved with different calculation in vac_estimate_reltuples(). One thing I have observed that 2nd parameter is_analyze of vac_estimate_reltuples() is currently not used. I cannot work on it till early next week, so others are welcome to join review. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
